くじらベーコン万歳

杉浦日向子の「ごくらくちんみ」を読んだ．本書は，様々な珍味を題材とした短篇集．ていうか，ショートショート．

余談だがショートショートっていうとSFのイメージが強いのは星新一のせいだろうな．本書のような私小説に近い感じの掌編小説をショートショートと呼ぶのには，いささか違和感がないわけでもない．

ま，それはそれとして．

なかでも印象的だったストーリーが「くじらベーコン」と題したお話．短いお話なのでまるっと紹介したいところだが，全文引用すると，それって引用なのか？ってことになるので，後半をちょいとばかり引用しよう．

薄いスライスが五枚．大半を占める脂身に，先細の竹箸で切れ目を入れると，むちむちっとした手応え．胡椒を多めにつけ，醤油へ，ほんのちょびっと浸し，食べる．

「んんー．サカナじゃない，まさしく，ケモノなんだよね．あったかい血と胎生の鼓動を，感じるー」

「大袈裟だなあ．ガツンと度合いの高い原酒もらおうか．マスター，ほんっと，このベーコン，ウマー」

「わたしもおいしいとおもいます．鯨は，日本の食文化の華です」

「だよねー．残さず使い切るもんねえ．なんで鯨捕っちゃダメなん．世界の大勢が，家畜っきゃ喰わないから，鯨の恩恵を知らないんだ」

「わたし，肉の脂けっこう苦手だけど，これはイケるんだ．なんか，ひと噛みで，うわっとコクがひろがって，お口が鯨．鯨まみれのマクを張るのよ．すっごいインパクト．殴られても気持ちいいみたいな」

以上，引用終わり．

まあ杉浦日向子って「お江戸でござる」に出てきてたくらいしか実は知らなかったんだけど，実に素敵な感性の持ち主だったんだなぁと，あらためて感服した次第．享年46歳．惜しい．実に惜しい．

「ごくらくちんみ」ぜひ読んでみてください．

初学者にやさしいデータ入出力の抽象化とは

かなり昔の話になるが，SSS2015という学会で「初学者向けプログラミング教育に関する意識調査 ― GUIとCUIのどちらがよいか？ ―」という発表をした．これは2つのプログラムについてGUIベースのものとCUIで提示したものとどちらが教育的であるかを検証したものであった．

その議論はかなり盛り上がり，示唆に富む意見もいろいろと頂戴することができた．SSS2015での発表と議論，皆さんから寄せられた自由回答でのコメントを踏まえてじっくり考えてみたところ，結局，GUIとCUIという対立軸はややミスリーディングであり，本質的な違いはもっと別のところにあるのではないかという結論に至った．すなわち，提示した2つのプログラム，その違いはGUIとCUIではなく，プログラム実行環境の違いにすぎないというものである．

さらにいえば，この実行環境の違いをどう捉えるか，そして，どちらを先に教示したほうが理解が進むか，という問題設定と理解すべきであった．もちろん，近年のWebシステムエンジニアになるのであれば比較的初期の段階でいずれも理解しておくべき概念であり，実際のWebシステムを実装するためにはいずれも求められる知識である（前者はフロントエンジニア，後者はサーバサイドエンジニア，という大まかな役割分担はあるかもしれないとはいえ）．

インタフェースの違いをどう教えるか

ある処理X（先の論文で提示した例では「文字列の反転」）という処理を考える．プログラミング教育のごく初期段階では，プログラム内部にハードコードして変数に値を与える例で説明しても問題はなかろう．しかし，実際のシステムでは，外部とのデータ入出力が不可欠である．そこで，古いタイプ（ここでは便宜上，UNIXerを「古いタイプ」と類型する）は「標準入力」「標準出力」というインタフェースの理解を求めた．

これらのインタフェースは，データを全て文字列のストリームとして表現するという抽象化をひとたび理解すれば，ごく自然に理解できると信じられているインタフェースである．しかし，「|」（パイプ）でコマンドを結びつけることやリダイレクトの概念，あるいは，キーボードからの入力やシェルが動作している端末エミュレータへの出力が暗黙のうちに標準入出力に結び付けられているといった抽象化を理解しなければならないというハードルが存在する．

一方，Webインタフェースで示されたプログラム（新しいタイプ）では，その部分はHTMLで表現されたGUI部品で，若干ではあるが具体化されている．なぜなら，テキストエリアという目に見える「入力する場所」「出力される場所」があり，それらがプログラムの中に示されているからである．

しかし，処理Xには本質的には関係ないはずのHTMLを理解しなければならず，また．JavaScriptで記述された処理Xの本体部分とそれらのGUI部品とを結びつけるためには，DOMの概念も正しく理解していなければならない．やはり，ここにもHTMLやDOMで表された入出力インタフェースの理解が求められるているだけであり，結局のところ新しいタイプでも入出力インタフェースの理解が不可欠ということである．

まとめ

以上を整理すると，この問題は，以下の3つの観点からの比較という側面を持つといえよう．

• 入出力インタフェースに関する抽象化レベルが，1. 高いか，2. 低いか
• ブラックボックス化されている入出力機構は，1.「標準入出力（Unix技術）」か，2.「HTML/DOM（Web技術）」か
• プログラムから入出力インタフェースに関する記述を，1. 極力排除するか，2. ある程度明示的に示すか

いずれも前者が古いタイプ，後者が新しいタイプである．以上を踏まえたうえで，改めて皆さんのご意見を伺いたいところ．なお，上記2つの他に，データベースに対するデータの入出力なんかも考えられるかもしれないが，いきなりそれはちょっと難しいだろう．皆さんはどうお考えになるだろうか？

参考文献

飯尾 (2015) 初学者向けプログラミング教育に関する意識調査 ― GUIとCUIのどちらがよいか？ ―, 情報処理学会 コンピュータと教育研究会 情報教育シンポジウム Summer Symposium in Sakaiminato 2015 (SSS2015), IPSJ Symposium Series Vol. 2015, pp. 17-22, 鳥取 境港

無名関数とラムダ式

Excelにラムダ式が導入されたというニュースが少し話題になった．ラムダ式，よく分からない，という人のために，ラムダ式の分かりやすい活用例である無名関数を用いて説明してみよう．この記事で，少しでもラムダ式に親しみを持ってもらえれば本望である．

無名関数

いきなりだが，Wikipediaの「無名関数」からその説明を引用する（太字は筆者による）．

プログラミング言語における無名関数（英語: anonymous functionあるいはnameless function）とは，名前付けされずに定義された関数のことである．無名関数を表現するための方法には様々なものがあるが，近年主流となっているのはラムダ式による記法である．

このように，ラムダ式とは無名関数，すなわち「ひとまとまりの処理だが名前が付けられていないもの」であると考えれば分かりやすい．なお，それに対して「ひとまとまりの処理でそれに名前が付けられているもの」は，皆さんおなじみの，関数とかメソッドとかサブルーチンなどと呼ばれるものである．

具体例

たとえば，単純な例だが次の関数定義を考えよう（言語はPythonとする）．これは，2乗するだけの極めてシンプルなものなので，説明は不要だろう．

def square(x):

  return x * x

さて，ここで，0から4までの数字が入った配列を考える．

A = list(range(5))

この結果，変数 A には [0, 1, 2, 3, 4] という値が格納される．ここで，全ての要素を2乗したい，つまり，先の square() を配列の各要素に全部適用したいということを考えよう．数学でいえば集合Bを集合Aの各要素が2乗されたものと考えて，集合Aから集合Bに対応させる各要素を2乗する写像 f : A → B を考えるということになる．これをそのままプログラミングとして表現するということだ．

Pythonでは map() が使える．map操作によってAにsquareを適用する．結果がmapオブジェクトになるため再びlist化してやる必要があるのが若干面倒ではあるが，上の写像は次の簡単なプログラミング（square()の定義を除けば1行）で表現できる．

B = list(map(square, A))

この処理の結果，変数 B には [0, 1, 4, 9, 16] という値が入る．Pythonインタプリタを用いて確認してみよう．

ラムダ登場

ところで，ここでAだのBだのという変数を使っているが，これって後でそれらを再利用することがなければ本来は不必要だということは，明らかだろう．すなわち，list(map(square, A))は，変数名Aを陽に用いることなしに，次のように書けばよいということである．

list(map(square, list(range(5)))

または

list(map(square, [0, 1, 2, 3, 4]))

でもよい．インタプリタで確かめてみれば，これでも先ほどと同様の結果が得られることを確認できる．では，square() はどうか？これもその関数を別のところで利用することがないのであれば，名前を付けるだけ無駄である．ここでラムダ式の出番である．名前が付いた関数を無名関数で置き換えるのがラムダである．Pythonのラムダ式は

lambda (引数): 処理

と書く．これを使うと，上記の式は次のように書ける．square()の定義も不要なので，ワンライナーになってしまった．スッキリ！

list(map(lambda (x): x*x, [0, 1, 2, 3, 4]))

以上の過程をインタプリタで試してみた結果がこちらである．確認されたい．

無名関数のメリット・デメリット

本稿では，map操作を用いてラムダ式のメリットを説明した．その他にも，Cのsort系関数に渡す4つめの引数，関数ポインタで渡している比較関数のような使い方でもその効果を発揮するだろう．本来，それらの処理でも名前の付いた「関数」を渡す必要はないのだ．その処理へのアドレスが渡せれば十分のはず．しかしCにはラムダ式が用意されていないので，仕方がなく関数ポインタでコードへのアクセスを渡しているにすぎない．

冒頭で紹介したWikipediaの記事には，無名関数のメリットとして名前の衝突が起こらないという点が指摘されていた．そりゃそうだろう．名前を付けないわけだから，衝突の起こりようがない．コードをシンプルに書けるだけでなく，このようなメリットもあるということだ．デメリットとしては名前が付いていないので再帰を書くには何らかの工夫が要るとあった．それもそうだが，再帰を書くときは，素直に普通の関数をかけば良いだろう．

mapとリスト内包表記

集合への写像をプログラミングで表現する方法としてmapを紹介したが，Pythonだと「リスト内包表記」という書き方で似たようなことができる．さきほど述べた配列Aの要素を全て2乗した配列Bを求めるコードは，次のように書ける．

B = [ x*x for x in A ]

これは関数square() を用いて次のように書いても同じ結果になる．

B = [ square(x) for x in A ]

ラムダ式の構文こそ陽に出てこないものの，考え方は同じであるということを理解できるだろうか．これらの比較から，「名前は付いていないけれど，一連の処理のまとまりですよ」ということを明示的に示すものがラムダ式であると考えることもできよう．

オンラインセミナーの新しいチャレンジ

横浜ユーラシア文化館の高橋健研究員による「土偶マイムで土偶を学ぶ」という講演を聴いた．オンライン講演である．今回，ちょっと変わった試みだったのは，ZoomやWebexなどのオンライン会議ツールによるウェビナーではなく，ClusterというVR的なSNSツールを利用したものだったということだ．

図はそのスクリーンショットである．中心にいる黄色い服を来ているのが私のアバター，ステージバックには3つのスクリーンがあり，正面がプレゼンテーション用，左側にチャットが表示され，右側は，うーん何に使われたんだろう，よく分からなかった．

ステージ上，端にいる鳥？みたいなアバターが講演者の高橋氏，その他，ロボットのようなキャラクターが他の参加者（受講者）のアバターである．アバターを切替えなければデフォルトではこのロボットが現れるらしい．この画面にはたまたま映っていないが，アバターを切り替えていた参加者は私以外にも数人いた．

参加してみての感想，メリットとデメリット

さて，率直な感想は「Zoomとかでやればよかったのに．ちょっとこのプラットフォームは残念だったなあ」というものである．講演者が操作に慣れておらずいろいろと待たされる時間が多かったという点は，まあ，割り引いてあげるとして，Clusterを使わんがためのオンラインイベントだったという感想は否めない．

プレゼン内容の表現としても画面の一部しか使えてないのが残念．スクリーンショットに示されているように，プレゼン内容の画面はデバイスの1/4ほどの面積しか使えていない．ステージに近づけばもう少し大きくすることはできそうだが，中央にいる自分のアバターが邪魔になる．また，左側のチャット画面はほぼ見えなかった．さらに，他の観客のアバターが邪魔になることもあった．それを考えると，自分も他人の迷惑になっていたんじゃないかという心配もしないでもない．あえて3DのVR世界に固執せず，講演が始まったら，画面いっぱいにプレゼン画面が拡がるモードがあったほうが良かったんじゃないかなあ．

あえてこのプラットフォームを使ったオンライン講演のメリットを指摘するなら，3DのVR操作で，イベント会場をぐるりと見渡すことができるという点だろう．講演してる人にとっては観客を一望できて「どれだけの人数が来てるかな？」ってのが分かってよいかも．リアル会場で，今日はいっぱい参加してくれて嬉しいな，会場が温まっているな，とか，あー，あまり参加してないのは残念だけど，足を運んでくれた人のためにしっかり喋ろう，というような気持ちになる．まあ，オンライン講義と同じで，ネットの向こうで「本当に聞いてくれているのか」っていうのは分からないわけだけれども．

オンライン講義「向け」追加機能の是非

ある会合（オンライン）に参加していて，大学もオンライン講義でいろいろたいへんですねという話題になった．その会合に参加していた某先生は「いやいやオンラインになっていろいろとやりやすくなりました．学生からの評判もよいです」と仰る．私は嘴を挟むのは遠慮していたが，間の悪いことにその直後に飯尾さんどうですか？と振られてしまったので「オンラインでやりやすくなった面もありますがオンラインで全ての関係性が希薄になったことを危惧しています．学生の声だって怪しい面もあり素直に受け取るわけにもいかない」と率直な意見を述べた．

オンライン化の課題

オンラインで関係性が希薄になることについてはこれまでもいろいろと指摘してきたことなのでここでは敢えて触れないが，やはり，顔の見えない学生たちに対して淡々と喋らねばならない現状の方法には異を唱えたいところだし，ふと動画がオンになったと思っていたら授業を聴いていた？のかどうかもよく分からない「ベッドに寝っ転がりながら受講していた学生の姿」が見えた事件（ビデオがオンになってしまったのはどうやら不慮の事故だったらしい．私も「どうも見てはいけないものを見てしまったようですね」とだけコメントして先に進んだ）などを思い出して，オンライン化を無条件で受け入れる気持ちにはなかなかなれない．

自分の専門性が人間と情報システムのインタラクションということもあり，コミュニケーションに関する身体性などについてもいろいろと考えてきたこと，あるいは，もともと情報系のエンジニアだったという背景からシステムを全面的に信用するわけにもいかないということなど，両手を挙げてオンライン万歳というわけでもない点を差っ引いたとしても，やはり，課題がまだあることを認めたうえで，慎重に進めていかないといけないのではということを改めて感じる．

カメラの遠隔操作機能

さて，そんな話をしていて，私の意見に共感を示してくださった参加者も何人かいらっしゃったので心強く感じたところではあったが，話の流れが，ふと，引っかかる話題に転がっていった．というのは「やはり受講している学生の姿が見えないのは難儀だよね（ここまでは完全に同意）今のオンラインミーティングツールってホスト側からゲスト側のカメラをオンオフできないじゃない，あれ，講義で使うにはホストがコントロールする権限ほしいよね」と仰った先生がいらした点である．

気持ちはわからないでもない．教室において対面で講義しているのであれば，居眠りしている学生がいたとして，その状況はすぐに分かるし，そんな彼ないしは彼女のところへ近寄り，そっと優しく起こしてあげる，なんてこともできる．

オンラインではそうはいかない．ネットの向こう側で，学生たちがどんな格好をしているかは完全に秘匿される．なので，カメラをこちらからオンにできたら緊張感も出るしよいだろう，という発想に至るのは，わからぬでもない．

追加機能の是非

しかし，その考えに私は同調できなかった．学生が見えないことに不満を感じている自分ではあるが，強い違和感を感じた．なんとなく，それは一線を越えてしまっているような気がする．

プライバシー云々の話もあるが，あくまで直感である．言葉にするのはなかなか難しい．なかなかモヤモヤする話題でもある．教室に集まるときは公共空間に来る前提で現れているが，自室というのはかなりプライベートな空間であり，そこに強制的なカメラを持ち込んでよいかが論点となるだろう．講義だから，授業だから，あるいは会議だから，が通用するか否かである．

かように，まだまだ議論は不十分であると私は考える．オンライン化とクチで言うのは簡単だが，実際のインプリメンテーションはなかなか難しい．

音声制御は恥ずかしい？

ブームはひと段落した感じもするが，それは，AI技術を活用した音声インタフェースは生活に浸透してコモディティ化した証なのかもしれない．OK, Google!，Hey, Siri! など，皆さん活用してますか？実は私は全く使っていない．だって恥ずかしいんだもん．

たまたまエアコンを新しくしたという知人のFacebook投稿をみていたら，音声制御するのに名前を付けなきゃならないという話題で盛り上がっていた．それを読んで，そういえばかつて似たような話題で盛り上がっていたなあと昔の記録を紐解いてみたら3年前の投稿が出てきた．

けっきょくのところ，OK, GoogleだのHey, Mercedesなんてのは主語を明確にする欧米の言語文化が背景にあるからだろう．主語を明確にしない日本に直輸入しても文化的インピーダンスミスマッチが発生してしまう．日本語みたいなハイコンテキスト文化を理解できるAIはまだまだなんだろうねえ．

追記

Facebookの某グループで本記事をシェアしたところ，「『ねえGoogle』は使ってる」というコメントを頂きました．ナルホド！

さっそく手元のiPhoneに「ねえSiri」って語りかけてみたらちゃんとSiriが起動するじゃないの．これは知らなんだけど，いちおうちゃんとローカライズしてるんだねえ．「おいSiri」とか高圧的な態度ではダメだった．いかな機械といえど，質問があるときは謙虚な態度でお願いしようね．

ペンタブの利便性を実感

講義のオンライン化に伴い，黒板（白板）への板書をデジタル化すべくペンタブを導入したことは，2020年度のオンライン対応が始まってごく初期のころに報告した（2020年5月）．1年間使ってみて，投資はまったく無駄ではなかったどころか，それまでの喰わず嫌いを深く反省するほどその効果を実感している．

何に有効だったか

当初の予定通り，板書代わりの利用は大活躍であった．うまく利用するコツは，オンラインミーティングツールに備え付けのホワイトボード機能を使うのではなく，別のお絵描きアプリ等を画面共有することである．私はMS OneNoteを活用した．このソフトウェアはお絵描きソフトというわけではないが，さらぴんの白い画面にペンタブで落書きをすることができ，自然なタッチで絵や文字を描ける．

また，採点されたレポートに赤を入れて返す，という作業もとても効率的にできた．Wordの校閲機能でもよいのだが，そこは歴史ある校正記号でまっかっかにしたほうが視覚的にもインパクトがあり教育効果があるのではないかという期待もある（比べてみたわけではないので，あくまで主観だが……）．校正記号に関しては演習でひととおり指導した．まあ，それほど難しいものでもない．

なお，提出手段を指定しないとWord文書で出したりPDFで出したりと学生は自由奔放にいろいろなファイル形式で提出してくるが，Word文書は「OSXのFinderで選択した複数のWordファイルをPDFに変換するAppleScript」を参考にしてPDFに一括変換した．Windowsだと相応のソフトウェアをインストールしていれば，コンテキストメニューから一括変換できるのかな？（ごめんなさい，Windowsは常用していないので知らない ※）．PagesやLibreOffice Writerなどで提出した学生もいたので，それは個別に対応した．

本の校正にも便利

講義や演習の話題からは逸れるが，本の校正作業でもペンタブを導入した有難みを感じた．

以前，プロの編集者から「やっぱり最後は紙でやらないと校正のミスが多い」という現場の声というか，実情を聞いたことがある．そのときは「そんなもんかなあ．まあ，そうだろうなあ」と思ったが，これはなんというか，不十分なデジタル化がそのような結果になっているのではないだろうか．

ものすごく大雑把ながら，紙とペン，PDF（マウス操作），PDF＋ペンタブ，という3つの環境について比較表を記してみた．

操作性の比較

まず，操作性について．これは間違いなく慣れている従来の紙と赤ペンに軍配が上がる．高解像度ディスプレイによってだいぶ追い付いたとはいえ紙の解像度はまだ優位性があるため細かな作業をそのまま（拡大せずに）できる点は紙とペンの利点であり，さらに，細かい作業から大きなマル付け（段落の移動など）まで，作業のダイナミックレンジも広い．「そのひと手間」が意外と精神的な負担になることは皆さん日々の作業で感じていることだろう．

単純なデジタル化，PDFをマウスなどで操作するケースは，残念ながらここに大きな課題が残されている．表では甘く△を付けたが，ペケでも致し方ないかもしれない．この操作性の悪さ，そして小さなディスプレイだと一覧できないことによる校正漏れなどが，編集者氏が言っていた校正ミスに繋がっているだろう．ここは，ペンタブないしは液タブの導入で大きく改善されるところである．かなり改善されるが，これで完璧！というほどでもないので，◎ではなく◯にしておいた．

検索性とその他の利便性

検索については，これはPDFに軍配が上がる．電子書籍等でも同じことが指摘されているように，デジタルコンテンツは「検索できる」というアドバンテージを持つ．この機能は，校正作業を受けて修正する作業において効果を発揮する．校正箇所を順番に検索して対応すればよいので，赤を入れられた箇所を「目を皿にして探す必要がない」．素晴らしい．

その他の利便性に関してはいろいろあるが，大量の紙を郵便でやりとりする必要がないとか，作業の履歴管理をしやすいとか，デジタルならではの利便性は多数あるだろう．同じような校正作業の指摘はコピペで省力化できるということに気付いたのも目からウロコであった．この点は，明らかにデジタル化による意義を感じるところである．

留意点

ただし，ペンタブ導入の効果を最大化するためには，いくつかの準備が必要だ．まず，モニタは大きく解像度の高いものを利用すべきだろう．私はMacBook Proの13''モニタだったので，若干，窮屈さを感じた．慣れというものは恐ろしいもので，これでもなんとかなっているのは我ながら凄いと思うが，やはり大きな画面のほうがミスは少なくなると思われる．

もうひとつ，板書代わりにはMS OneNoteを使ったほうがよいと述べたように，PDFへ校正記号を書き込む作業も，ソフトウェアによって使い勝手が大きく左右される．PDFへのちょっとした書き込みであればmacOS添付のプレビューでも問題ないが，手書きでコメントを書き込んだり，細やかな記号を書き込もうとすると，なかなかうまく書けずじれったい思いをする．一方，Adobe Acrobat Readerの添削機能は使い勝手がよい．ソフトウェアを選ぶことも大切である．

補足

※ WindowsでコンテキストメニューからPDFを作成するには，標準プリンタをPDFプリンタドライバに設定しておいて，コンテキストメニューの「プリント」を選べばよいとのこと．教えてくださった皆様，どうもありがとうございます．

補足2

iPad等のタブレット端末は，表面の保護フィルムで書き心地が全く異なるらしい．ツルツルのシートではなくザラザラの保護フィルムを使うと紙のようなタッチで書けるとのこと．ただし，摩擦によるペン先の消耗が激しいので注意だそうだ．

論文誌編集長へのお誘い

あちこちの国際会議で研究成果を垂れ流していると，まあ，いろんなところからテキトーなお誘いを頂くようになる．今日は新しい論文誌を作るので編集長（Editor-in-Chief）に就任してくれないか？とのメッセージを頂戴した．

それはそれで名誉なことであるし，マトモなお誘いなら引き受けることは吝かでもないのだが，そもそも出版社がいわゆるPredatory publisherとの疑いが持たれているということで有名な出版社なので，気が引ける．さらに，なかなかリクエストが厳しくて，ただでさえいろいろ業務に忙殺されているなかで，私には突きつけられた条件に対応できる自信がない．

20人の編集委員を用意せよ ― それもh-indexが20以上の人を選べとのこと．そもそも私のh-index自体そんなに高くないのに，どうせよと？名前挙げるだけなら，まあ，テキトーなDB検索してリストアップすることくらいであればできないこともなかろうが，そんなイイカゲンな仕事でいいのか？また，年に1度以上は論文を寄稿せよとか，卓越した科学者をゲストエディタとして毎年呼んでこいとか，なかなか厳しい条件を並べている（下記）

まあとりあえず放置かな．しかし世の中は様々なSPAMがあるもんだなあと．いろいろ面白い．

Zoomの動画埋め込み機能

動画の埋め込み機能がZoomの最新版（5.5）に追加されてこれはありがたいと手放しに喜んでいたわけですが，そうするとこういうイタズラをやりたくなるわけで．

まあしょうむないイタズラですが，シンセの多重録音みたいに，面白い使い方ありますかねえ？w

Zoomがまた進化（動画共有機能の追加）

Zoomが5.5.0にアップデートされて，またいろいろな機能が追加されたとのこと．「窓の杜」の記事によれば，背景のぼかし機能が追加されたことが報じられているが，私にとっては動画を直接共有できるようになったことが大きい．ぼかし機能は既にWebexにあったものだが，こうやって切磋琢磨してアプリは進化していくんだなあ．

というわけで，早速やってみた．例によってぼっちなので（苦笑）ひとりZoomを録画することで，どう配信されるかを確認してみている．ひょっとしたら配信と録画で異なる可能性も否めないので，その点はご容赦いただきたい．実際に動画を埋め込んだ動画は，こんな感じになる．

やり方とTips

では，やり方とTipsを簡単に紹介する．

まず，いつもどおり画面の共有を行う．ここで，そのままでは動画の選択が出てこないので，上の「詳細」タブを選択することが重要である．「詳細」を選ぶと，「ビデオ」というボタンが出てくる．

デスクトップ上に動画ファイルが置かれていることにも注目してほしい．このビデオを共有してみよう．なお，左下にみえる「音声を共有」にチェックを入れておかないと，動画に含まれる音声が共有されないので注意が必要だ．

共有する動画ファイルを選ぶ画面が出てくる．この画面のスナップショットは，実は１回めに失敗したときのもので，左下の「音声を共有」にチェックが入っていない．ここのチェックを忘れると，サイレントムービーになってしまうのでご注意を．

ビデオ共有画面はこんな感じになる．動画の再生の停止や再開，再生位置のコントロールなどもできる．なお，全画面にせずとも共有された画面は動画の画面になるので問題ない．再生しているビデオは私のお喋りで，右上に出ているのは今のリアルタイムの私．ビデオでお喋りしている自分に自分自身がツッコむ，なんて芸当もできるよ．