THINKING MEGANE

2020

今年は、なんと言っても、6月の初めてのジャーナル論文採録が文句なしに一番嬉しかった出来事だった。 ペパボ研究所に入って3年半。 本当に長かったし苦しかった。 それでもこの期間にたくさん自分自身や研究と向き合うことで、多くのものを得ることができたと思う。 今は、ただただ「巨人の肩に乗ることから逃げずに真摯に向き合い一歩づつ精進して」いる。

10月には、博士後期課程に挑戦し、無事に入学することができた。 12月のインターネットと運用技術シンポジウムではジャーナル論文の研究を発展させる手法が採録され、優秀プレゼンテーション賞も受賞することができた。 来年は国際会議に挑戦する。

長い暗中模索を抜けたが、スタートラインにやっと立てたとも言える。 遅れを取り戻すことを動機とはしないが、2021年は、可能な限り、適切な粒度で継続的に分野への貢献を出していきたい。 また、その貢献を通して周りの人へ直接的間接的に良い影響を与えたいと思う。

そのためにも、習慣と計画をうまく使い、仕組みによって淡々と自分を駆動していきたい。 2020年は1月末からリモートワークに完全移行したが、毎朝の論文読み会によって生活リズムが崩れることはなく研究に取り組めた。 毎日の業務後に進めるよう計画していた、大学基礎数学の参考書は、微分積分、線形代数、確率統計を一通りこなすことができた。 一方で、研究開発において、習慣と計画は適用が難しいと感じている。 研究には終わりがないため、どこまでの試行錯誤を区切りとするのか判断がつきにくい。 また、アイディアは無限にあるため、いろいろなことをやりたくなり、優先順位の判断がつきにくい。 つまり、全体をブレイクダウンしてルーティーンに落とし込むところに苦労している。 ここに関しては、研究日誌のような短期のアウトプットに加えて、もう少しだけ長い視点での判断をする機会を計画や習慣として組み込んでいきたい。 まずは、その観点でも指導教官や研究所のみんなにも相手になってもらおう。

2020年は光が見えた年だった。 2021年からは、この成果を普段から出せるよう、そして一つ上を目指せるようにしていこうと思う。 そして、その成果から行動の意義が伝わるような良い影響を与えられるようになりたいと思う。 来年もよろしくお願いします。

実績

以下、実績を列挙する。

表彰

2020年は2回の表彰があった。 コミュニティ活動と研究活動の両面で表彰をいただくことができて、非常に嬉しい。

論文

国内ジャーナル論文1本、査読付き論文1本。研究報告については第一著者のものが1本。 また、今年は研究報告のラストオーサーを2本務めた。

  1. 三宅 悠介, 峯 恒憲, Synapse: 文脈に応じて継続的に推薦手法の選択を最適化する推薦システム, 電子情報通信学会論文誌D, Vol.J103-D, No.11, pp.764-775, Nov 2020.
  2. 三宅 悠介, 栗林 健太郎, 変化検出と要約データ構造を用いた利用者の嗜好の変化に迅速に追従する多腕バンディット手法, インターネットと運用技術シンポジウム論文集, 2020, pp.1-8, Nov 2020. [発表資料]
  3. 三宅 悠介, 栗林 健太郎, 非定常な多腕バンディット問題における変化検出アプローチの線形モデルへの拡張, 研究報告インターネットと運用技術(IOT), Vol.2020-IOT-50, pp.1-8, July 2020.[論文] [発表資料]

国内発表

技術イベント、研究会での発表で計6回(学会の研究会、シンポジウムを除く)。 Fukuoka.go、WSA研究会といったお馴染みのところに加え、GMOのテックカンファレンス、エンジニアフレンドリーシティ福岡のような声をかけていただいた登壇もあり、バランスは良かったと思う。 来年は、国際カンファレンス登壇が最初の目標だが、国内でも参加したことがない技術カンファレンスや勉強会なども挑戦してみたい。

  1. 三宅 悠介 嗜好伝達コミュニケーションの効率化を目指した伝達方式の検討, Web System Architecture 研究会 (WSA研) #7, 2020年11月.
  2. 三宅 悠介 なめらかなシステムの実現に向けて, GMO Developers Day 2020, 2020年7月. [動画]
  3. 三宅 悠介 Go言語でシミュレーション用のシンプルなフレームワークStageをつくった, Fukuoka.go#16(オンライン開催), 2020年7月.
  4. 三宅 悠介 軽量なインデックス機構を用いた全文検索ツールの高速化の検討, Web System Architecture 研究会 (WSA研) #6, 2020年4月.
  5. 三宅 悠介 Adaptiveなウィンドウを求めて 〜サーベイと実装 Go言語編〜, Fukuoka.go#15 + 鹿児島Gophers(オンライン開催), 2020年3月.
  6. 三宅 悠介, 田中 孝明, 白石 憲正, 浜崎 陽一郎, 松口 健司 トークセッション / エンジニアと企業が描く未来のかたち, エンジニアフレンドリーシティ福岡フェスティバル, 2020年2月.

OSS

変化検出の手法をはじめ、シミュレーションのフレームワークなど研究開発で取り組む分野の実装が増えてきた。

  • ADWIN-V: ADWIN-V is an adaptive windowing algorithm for vector data.
  • stage: Simple and flexible simulation framework for Go.
  • sifter: A lightweight index for full text search tools using bloom filter.
  • adwin: Adwin is an adaptive windowing algorithm.
  • exponential-histograms: Exponential histograms is a data structure for sliding windows.
  • random_multivariate_normal: Random number generator from a multivariate normal distribution.

コミュニティ活動

昨年度の活動や昨今の状況でのオンラインでの活動が評価され、表彰やインタビューを受ける機会をいただき非常にありがたいことであった。 一方で、Fukuoka.go自体の活動実績は2回と例年に比べかなり少なめであった。 オンライン開催での主催者側のモチベーションをどう維持するかも課題である。

ブログ

13本。結果だけでなく、どうしてその考えに至ったかなど、その経緯、考えをまとめるカタチの文章をいくつか出すことができた。特に論文執筆のエントリのような自分なりのまとめは定期的に書いていきたいと思う。

嗜好伝達コミュニケーションの効率化を目指した伝達方式の検討

このエントリは、第7回 Web System Architecture 研究会 (WSA研)の予稿です。

嗜好伝達コミュニケーションの効率化を目指した伝達方式の検討

はじめに

適応的なシステムの実現には、システムが利用者の状況をよく知ることが重要になる。 ECサイトのシステムであれば、利用者の嗜好を把握することで、最適な商品を提案できると考えられる。

ECサイトのシステムが利用者の嗜好を把握するためには、特に初期段階における利用者との一定量のコミュニケーションが必要となる。 明示的なコミュニケーションであれば、システムは利用者に、年齢や居住地、興味関心などのプロファイルの登録を依頼する。 暗黙的なコミュニケーションであれば、システムは利用者の、閲覧や購買、検索履歴を通して利用者の嗜好を把握する。 システムはこれらのプロファイルの登録や履歴の蓄積なくして、適応的に振舞うことが難しい。 一方で、これらのコミュニケーションは利用者に負担を強いる。 これには、システムごとに発生するプロファイルの登録や履歴蓄積のための労力的な負担の他、プライバシーを守りたいという意識的な負担も考えられる。

本研究では、利用者の嗜好伝達に纏わるコミュニケーションの負担を低減しつつ、適応的なシステムによる利便性を常に享受できるインターネット世界に向けて、嗜好伝達コミュニケーションの効率化のための伝達方式の検討を行う。

嗜好伝達コミュニケーションの課題

嗜好伝達コミュニケーションの課題整理にあたり、本研究における「嗜好」を定義する。 まず、嗜好(preference)とは「利用者の素性(feature)」に基づく「対象(content)への反応(reaction)」と考える。

preference(feature,content) #=> reaction

対象(content)はシステムごと(ECサイトごと)に異なるため、嗜好伝達にはシステムごとに個別のコミュニケーションが求められる。 利用者の素性(feature)を示すか、直接、対象(content)への反応(reaction)を示す行為がこれに該当する。 推薦システムでは、利用者の素性(feature)を示す場合、類似する素性の群の反応を用いて利用者の嗜好が推測される。 対象(content)への反応(reaction)を示す場合、この反応から、もしくは類似する群から利用者の嗜好が推測される。

本研究では、この、利用者の素性(feature)の伝達か、対象(content)への反応(reaction)の伝達に纏わるコミュニケーションの効率化を検討する。

利用者の素性(feature)の伝達の課題

  1. システム内に限定された利用者の素性
  2. 適切なデータ構造が不明
  3. プライバシー保護が必要

「1. システム内に限定された利用者の素性」について、利用者の素性(feature)には人口統計的な情報だけでなく、行動データが考えられる。 利用者の素性をより知るためには、システムを横断して蓄積された行動データを得られることが望ましい。 しかしながら、通常、システムの把握可能な履歴はシステム内に限定される。 オンライン広告に見られるアドネットワークやオーディエンスデータの利用により、横断した行動を特定できる。 しかしながら、これらのcookieなどを用いた名寄せに関してはプライバシー保護意識の高まりもあり、代替手段を検討すべきである(要リファレンス)。

「2. 適切なデータ構造が不明」について、利用者の素性(feature)となり得る要因は無限に検討可能なことから、これを全てのシステムで共通に管理することは困難である。 例えば、訪問したサイトを利用者の素性として扱うとして、多次元のベクトルデータで表現すると、各次元とサイトの紐付けやサイトの追加削除を管理しなければならない。

「3. プライバシー保護が必要」について、人口統計的な情報だけでなく、行動データを含む利用者の素性は多くのセンシティブな情報を含むことから、利用者側が開示するにあたって内容の制限が求められるであろう。

対象(content)への反応(reaction)の伝達の課題

  1. システム内に限定された利用者の嗜好
  2. プライバシー保護が必要

「1. システム内に限定された利用者の嗜好」について、前述の通り、プロファイルの登録や履歴蓄積のための労力的な負担が発生する。 対象(content)はシステム内に限定されるため、システムごとにその反応を提示しなければならない。 この時、利用者の嗜好をより知るためには、できるだけ多くの対象(content)に対する反応(reaction)を示せることが望ましいが、労力的な負担は比例して増加する。

「2. プライバシー保護が必要」について、利用者の嗜好傾向は(素性と比較して間接的ではあるものの)センシティブな情報を含むことから、利用者側が開示するにあたって内容の制限が求められるであろう。

嗜好伝達コミュニケーションの効率化の検討

利用者の素性(feature)の伝達の効率化

本研究では、利用者の素性(feature)の伝達の効率化のため、人口統計的な情報だけでなく、システムを横断した行動データを局所管理するアプローチを検討する。 無限に検討可能な要因を共通して扱うため、Key-Value形式のデータ構造を採用する。 また、システムへの提示時に、このKey-Value形式のデータをBloomFilterに変換することでプライバシー保護を試みる。 すなわち、BloomFilterの偽陽性に着目した素性であるKeyを断定することができない特性を利用する。 また、BloomFilterが保存する要素数に依存しない特性を利用して、無限に検討可能な利用者の素性の要因を固定次元で扱うことができる。

なお、あるシステムに提示されるBloomFilterのパラメータは全ての利用者が同じものを用いる必要があるが、これらの共有方式についてはここでは検討しない。

対象(content)への反応(reaction)の伝達の効率化

本研究では、対象(content)への反応(reaction)の伝達の効率化のため、嗜好モデルを局所管理するアプローチを検討する。 提案手法では、システムを横断した行動データから、嗜好モデルを構築するローカルエージェントを設ける。 構築される嗜好モデルはこれまでの行動データから、未知の対象(content)への反応(reaction)を精度よく推測する。 ローカルエージェントは、このモデルを使い、システムに対する対象(content)への反応(reaction)の伝達を代理する。 具体的には、利用者が新しいシステムへのアクセスする際に、(システムが対応していれば)この嗜好モデルを使って、先方のシステムから示された大量の対象(content)への反応(reaction)を回答する。 先方のシステムは、十分な量のコミュニケーションを終え、利用者に利便性の高い状態から利用を開始してもらうことができる。 また、予めローカルエージェントの嗜好提示範囲に制限を持たせておくことで、プライバシー管理も行えると考える。

なお、これらの方式は検討段階であり、ローカルエージェント、嗜好モデルの具体的な実装はこれから検討していく。

評価

利用者の素性(feature)の伝達の効率化の評価

提案手法の有効性を判断するため、BloomFilterに変換した素性によって嗜好情報の伝達能力を評価した。 評価として、素性を特徴量として用いた多腕バンディットのシミュレーションを行った。 元の素性と比較して提案手法の素性で、どの程度精度に変化があったかを確認した。

以下は、腕の数が30、密度(*後述)10倍の実験設定の時の、BloomFilterの次元数と精度の変化を表している。 ここで、精度の変化とは、元の素性を使ったシミュレーションで選定された腕と同じ腕を選定できた割合を言う。

1: 1.0
2: 0.60425
3: 0.424515
4: 0.38845
5: 0.35002
6: 0.32798
7: 0.335945
8: 0.307885
9: 0.31443
10: 0.317955
20: 0.311235
30: 0.3068
40: 0.320385
50: 0.30193
60: 0.31655
70: 0.33412
80: 0.319935
90: 0.309365
100: 0.33812

BloomFilterで表現された素性をコンテキスト情報として用いた推定には誤差が生じる。 そして、この誤差の増加はBloomFilterの偽陽性率の増加に従う。 今回の問題設定では、例えば100次元のバイナリベクトルを50次元のBloomFilterで表現することである(このような状態を本研究では密度2倍と考える)。 また、多腕バンディットでは腕の本数の増加に従い、不確実な状況において偶然当たる確率が下がる。 これらを考慮して、100次元のコンテキスト情報を10次元へ圧縮、30本の腕という問題設定でベストな腕を選択できた割合をサンプリングによって求めた。 結果として正しい腕を選択できたのは33%程度であった。 現実の推薦システムにおいてあり得る程度のスケールでも精度に対して大きな影響が発生することがわかった。

対象(content)への反応(reaction)の伝達の効率化の評価

今後、実装と評価を行っていく。

発表スライド

発表後の議論では、アプローチに対する新規性や有用性について、また、Webサービスへの適用のアイディアについても話すことができ、今後にとって非常に有意義なものとなった。

発表を終えて

今回のWSA研では、最初のアプローチの失敗で終わらず、やりたいことに立ち返り、より良いと思われるアプローチも検討できた点が良かったと思う。 長期間続く研究であればこそ、個々の結果に一喜一憂ではなく全体として進んでいけるよう全てを糧にしていきたい。

そして、このような研究のアイディア段階から前向きに意見を出し合うことができる機会を定期的に設けることができるWSA研はとても良いコンセプトの研究会だと思う。 何よりその時間はとても楽しい。

Webシステムアーキテクチャに関する運用知見を研究的アプローチで前進させること興味がある方は次回開催の参加を検討してみてはいかがでしょうか。

ペンタブレットでリモートワークのコミュニケーションを改善する

リモートワークが続く中、口頭での説明を補足するため電子ホワイトボードなどを使ったコミュニケーションの機会が増えています。 一方で、手書きの気軽さに追従できないマウスを使っていると、書くより口頭での説明の方が早いと電子ホワイトボードを使わずにすましてしまうこともありました。

しかしながら手書きの表現力を生かしたコミュニケーションは捨て難く、ペン型の入力装置を探していました。 iPadは入力装置としても優れていますが、他にも活躍する場面が多いこと、連携時にも一手間かかることから、常時接続できる据置型のシンプルな入力装置としてペンタブレット(いわゆる板タブ)を導入しました。 今のところ、快適に利用できているので、簡単にご紹介します。

機材

家にあったワコム Intuos Comicを使っています。

僕の用途であればSサイズ(210x169mm。ただし入力領域はこのうち155x95mm程度)で十分でした。 こちらはUSB(Type-A)でPCと接続します。すでに旧モデルとのことで、これから購入するならBluetoothで接続できる新しいものが良さそうです。

また、接続先のPCはMacBook Pro (15-inch, 2019) です。 macOS Catalinaですが、ワコムのサイトに公開されている最新のドライバをインストールした上で、「セキュリティとプライバシー」で必要なアプリケーションに許可を与えることで利用できるようになりました。

設定

後述しますが、タブレットの座標検出は絶対位置の指定です。 小さいタブレットに大きな画面をマッピングして使うのは向いていないため、画面内の限られた範囲をマッピングして利用しています。

僕の用途では電子ホワイトボードとしてJamboardを利用しており、画面内の決まった位置(左上)で扱うため、この範囲をタブレットの操作範囲としました。 これによってJamboardの表示範囲とタブレットの入力領域がある程度同じになり、違和感なく入力できるようになりました。

ワコムのタブレットの場合、以下のように設定できます。

wacom

タブレットの操作

普段の業務は、キーボードとマウスで済むため、タブレットは初めて利用でした。 そのため、操作に慣れるまで少しだけ戸惑いましたが、以下のサイトを見て、基本を理解しました。

以下だけ理解すればすんなり使えると思います。

  • ペンをタブレットから浮かした状態でポインタを移動
  • ペンをタブレットにつけるとクリックしながらポインタを移動することに相当
  • タブレットの操作領域が画面にマッピングされている

まとめ

Google MeetからJamboardを開いて参加者にリンクを共有できるようになり、便利になりました。 利用までの手間を小さくできるよう、常時接続型のシンプルなタブレットを導入することで、Jamboardを積極的に利用することができ、手書きの気軽さと表現力を活かしたコミュニケーションの改善につながっていると感じます。

今後改善したいところとしては、ペンのボタンへのアクション割り当てなのですが、Jamboardの消しゴムやレーザーポインタ切り替えにショートカットがなく、まだ実現できていない状態です(フィードバック送ろう)。

まだまだリモートワークも続くでしょうから、引き続き、入力機器の構成や工夫など進めていきたいと思います。

構造を意識した抜け漏れがなく主張点が明確な論文執筆

はじめに

研究者は、自身の研究の有用性を主張するため論文を発表する。 しかしながら、研究の有用性を主張するために、抜け漏れがなく主張点が明確な文章を書くのは、慣れないうちは難しい(慣れても難しい)。 本エントリでは、論文の構造を見出だす工程とその構造を書き下す工程を明示的に分離することで、抜け漏れがなく主張点が明確な論文執筆を行う方法を検討する。

論文執筆の課題

前述の通り、研究の有用性を主張するために、抜け漏れがなく主張点が明確な文章を書くのは、慣れないうちは難しい。 これは、主張の整理と文章の生成を頭の中で同時にやろうとしていることが原因であるように思う。

第一に、主張の整理は複雑なタスクである。 研究の有用性の主張は、いくつかの課題や提案、評価といった複数の要素と、要素同士の関係性のあり方、すなわち「構造」を持つ。 要素やその関係性の増加に伴い、構造は複雑になるため、頭の中だけで網羅しつつ整合性を取り続けるのは困難である。

第二に、主張の構造を文章に落とし込むのは複雑なタスクである。 文章は連続した文から構成され、逐次的に記述される。 そのため、要素同士の関係性を含む主張の構造を書き下すためには、文同士の局所的な繋がりに加え、段落や接続詞による大局的な繋がりを表現しなければならない。 頭の中の主張の構造を余さずに正確に文章へと変換するのは困難である。 主張の構造が明らかでない段階では尚更である。

抜け漏れがなく主張点が明確な論文を書く

論文執筆が難しい理由は、主張の構造を見出だすこと、この構造を文章に落とし込むことという複雑なタスクを同時に行うためだと解釈した。 そこで、これらのタスクを明示的に分離する方法を考える。 この時、主張の構造を見出だすタスクの成果物を文章としてしまっては、主張の構造を文章に落とし込むタスクを兼ねてしまう。 主張の構造を見出だすタスクには必要な要素を文単位で表し、これらの関係性を表現できる形式が望ましい。 本エントリでは、このタスクをつなぐ中間表現を論文ストラクチャーと名付ける。 提案する論文ストラクチャーを以下に示す。

structure

提案する論文執筆では、この論文ストラクチャーを埋めていく工程と、論文ストラクチャーをもとに主張を文章に落とし込む工程を繰り返すことで執筆を行う。

主張の構造を見出だす(論文ストラクチャーを埋める)

以下、埋めるべき内容について簡単に説明する。 はじめに②と⑤から主張を明確にし、その主張をストーリー立てて仕上げるよう残りの項目を埋めていくと良い。 なお、③④⑥はリスト形式かつ対応づけを行えるため、ストーリー内の根拠の抜け漏れを防ぐことができる。

② やりたいこと

⑤と合わせて、主張を明確にするために重要な要素。 リサーチクエスチョンとして、何を解決したいのか、達成したいのかを一文で述べる。

システム・ソフトウェア開発の論文では、提案手法によって、どのような理想の世界に近づくのかを示す。

  • 例)実行環境の変化に素早く適応する [*1]
  • 例)文脈に応じて継続的に推薦手法の選択を最適化する [*2]

⑤ やったこと

②と合わせて、主張を明確にするために重要な要素。 リサーチクエスチョンをどのようなアプローチ、着眼点をもって解決、達成したかを一文で述べる。

システム・ソフトウェア開発の論文では、開発したシステムやソフトウェア、アーキテクチャなどの特徴を示す。

  • 例)恒常性を持つシステムアーキテクチャ(を提案・開発)[*1]
  • 例)多腕バンディットを用いたメタ推薦システム(を開発)[*2]

① なぜ、やりたいのか

②への導入となる要素。 その研究の価値や意義を述べる。

システム・ソフトウェア開発の論文では、提案手法によって、どうして、そのような理想の世界に近づけたいのかを示す。 世間一般的に解決すべき課題として位置付けるも良いし、これまで世間が気づけていなかったけれども見方を変えて課題として捉え直した、のようにしても良いと思う。

③ なぜ、できないのか

②に対しての課題であり、⑤のアプローチへの導入となる要素。 理想となる世界に対しての(主に)技術的な課題を述べる。 多くの研究では、従来の研究成果で未解決、もしくは改善が必要とされる領域についてサーベイ結果が該当する。

なお、ここは複数の要素が挙げられるため、論文ストラクチャー上は「A、B、C…」とリスト形式で記述する。

④ どうやって、解決したのか

③の複数の課題に対する個々の解決手段であり、⑤の詳細となる要素。 提案手法である⑤がどのような方法で課題を解決するのかを述べる。

ここは対応づけを行うことでストーリー内での根拠の抜け漏れを防ぐことが目的であるため、③の個々の課題に対する解決手段を「A’、B’、C’…」とリスト形式で記述する。

⑥ 本当に、できたのか

③の課題を④の手法で解決できたことを示す要素。 評価とその結果を述べる。

ここも対応づけによる抜け漏れを防ぐことが目的であるため、③④の個々の課題、手法に対する評価内容を「A”、B”、C”…」とリスト形式で記述する。

構造を文章に落とし込む(論文ストラクチャーから文章を作る)

論文ストラクチャーを埋めたら、各項目を使って論文の文章の雛形を作っていく。

タイトル

②と⑤を組み合わせることは主張を端的に表現したタイトル案を作ることができる。 よく使われるパターンは「⑤を用いた②」「②が可能な⑤」などであろう。

概要

①から⑥を順番に並べることで抜け漏れのない概要案を作ることができる。 典型的な例では以下のようにつながれる。

  • ①の状況になっている
  • そのため②が求められている、必要となる
  • 一方で③A…の課題がある
  • 本研究では⑤を提案する
  • 提案手法では④A’…を用いて課題を解決した
  • 評価では⑤A”…によって有効性を確認した

1. はじめに

概要と同じく①から⑥を順番に並べることで案を作ることができる。 ここでは、パラグラフのトピックセンテンスが論文ストラクチャーの各項目になるように配置し、各パラグラフに説明とリファレンスを追加していくと良い。

2. 関連研究

③の各課題を単位とする節やパラグラフを並べることで案を作ることができる。 ここでは、各課題がなぜ発生するのか、解決できていないのかを説明するために、従来手法の説明を加えるのが一般的である。

3. 提案手法

④の各手法を単位とする節やパラグラフを並べることで案を作ることができる。 ここでは、③との対応づけが明らかになるようにできるだけ順序を維持し、また対応する課題について明記すべきである。 また、⑤を用いて提案手法全体の概要と達成できる事柄について導入部分で触れておくと良い。

4. 評価

⑥の各評価を単位とする節やパラグラフを並べることで案を作ることができる。 ここでも、③や④との対応づけが明らかになるようにできるだけ順序を維持し、また対応する課題、手法について明記すべきである。

5. まとめ

②と⑤からリサーチクエスチョンとこれに対する提案をまとめる。 また、⑥の結果を踏まえ解決した③を明記する。 最後に研究を発展させるための今後の予定を述べる。

おわりに

本エントリでは、抜け漏れがなく主張点が明確な論文執筆のために、論文執筆の複雑なタスクを分離し、主張の構造を見出だすタスクと、この構造を文章に落とし込むタスクという二つのタスクを交互に行う方式を提案した。 また、このために論文ストラクチャーと名付けた主張の構造の整理に適した表現形式を提案した。

提案手法によって、論文の品質を一定に保ちつつ初稿までの執筆時間を短縮する。 加えて、論文ストラクチャーを通した研究成果共有によって共著者との早期の意思疎通が容易になり、手戻りを防ぐ効果が期待できる。

あとは良い研究をするだけである(それもまた難しいのであった)。


参照

  • *1: 松本 亮介, 近藤 宇智朗, 三宅 悠介, 力武 健次, 栗林 健太郎, FastContainer: 実行環境の変化に素早く適応できる恒常性を持つシステムアーキテクチャ, インターネットと運用技術シンポジウム2017論文集,2017,89-97(2017-11-30), Nov 2017
  • *2: 三宅 悠介, 峯 恒憲, Synapse: 文脈に応じて継続的に推薦手法の選択を最適化する推薦システム, 電子情報通信学会論文誌D, Vol.J103-D,No.11,pp.-,Nov. 2020. (to appear)

九州大学大学院システム情報科学府博士後期課程に入学します

先日8/7、九州大学大学院システム情報科学府博士後期課程に無事合格しました。 10/1より入学します。 専攻は情報知能工学[*1]です。

39歳、文系学士から修士を飛ばして理系の博士課程への挑戦となった経緯や入試に向けた準備などまとめます。

略歴

大学では環境政策を学びましたが、工学的なアプローチの解決手法の方に興味を持ち、いろいろあってソフトウェアを扱える仕事につきました。 2012年に転職し、現職のGMOペパボでインターネットサービスのWebアプリケーションの開発・運用維持業務に携わってきました。 2017年より同社の研究職として情報システムの自律適応等の研究に従事しています。

研究員になった理由

サービスの運用開発の傍ら、ログ活用基盤の構築に取り組み、サービスを動的に改善していくための仕組みづくりと機械学習に興味を持ち始めたところ、その前年に設立したペパボ研究所でやってみませんかと@antipop所長に誘われました。

当時、ソフトウェア開発という非常に強力で柔軟な相棒を得て、OSSを楽しく量産する一方で、独学でやってきたこともあり、解決できる課題規模やアルゴリズムなど実装力に関する頭打ちを感じていました。 そんな折、コンピュータサイエンスや研究的なアプローチを学ぶことでここを突破できるのはないかと思えるこの誘いは非常に魅力的でした。

完全に未知の職種であること、天職だと思っていたエンジニアからの職種転換ということなど、悩む部分は正直多かったですが、所長との面談の中で「今までやっていることに論文書くのが加わるだけです」と後押しされ、その日のうちに決めました。(今思えば論文として研究をまとめるそれが一番難しいじゃ〜〜という気持ちでいっぱいですが興味があればやってみましょうと後押ししてくれたんだと思ってます)

実際に、今進めている研究も、インターネットサービスの運用維持の中で発生する課題を、研究というアプローチを用いて解決、サービスへ還元するという、エンジニアリングに研究が加わった方式で進めており、これまでのスキルも十分に活かしながら、研究観点での新規性・有効性・信頼性を追求することができています。

博士後期課程に入学した理由(大学の選定理由)

自身の研究の発展はもちろんのこと、研究を推し進めていく力を高めたいと考え、博士後期課程へ挑戦しました。

僕の3年間の研究への取り組みは全く順調ではなく、研究活動もテーマも解決手段も評価も論文執筆も暗中模索で、そのくせいつの間にか年齢と共に大きくなっていた自意識が、光となるはずの先達からのアドバイスも歪めてしまっていました。 結果として、最初の2年ほどは迷走しており、研究所の皆さんには迷惑をかけてしまいました。

今年の6月に初めてジャーナルの採録通知をもらい、研究者としての一歩を踏み出したものの、研究への取り組み方はまだまだ下手くそだなあと自分自身考えています。 具体的には、課題解決だけでなく、問題自体への向き合う時間を見直していく必要がありそうです。 過去の迷走の中で、かろうじて掴んだことは、「研究とは、ある問題設定に対する解釈を深めることであり、その問題設定に対して向き合った量が結果につながる(のではないか)」というものでした。 何が課題なのか、どういう世界があるべきなのか、これらは瞬時に明確になるものではなく、試行錯誤やアウトプットとフィードバックによって徐々に練られていく問いですが、この工程を避けてしまうと小手先や思いつきの対策に留まる、もしくは不要に複雑なだけの解法の適用に陥ってしまいます。 周りを見ても、良い研究だなあと思うものは、課題そのものを高度に解決するのはもちろんのこと、問題設定自体にきちんと向き合うことで、研究の位置付けを明確にし、提案手法の汎用性を高めているものがたくさんあります。 特に、モノの見方自体を少しでも変えるような問題設定に昇華した研究には尊敬すら覚えます。 博士後期課程では、自分の研究というものを確立する過程を通して、世界をよくするような研究を推し進める力を高められたらと考えています。

10月より指導いただく峯先生とは、幸い、既に共著で論文執筆する機会があり、専門性の観点だけでなく、研究の課題や貢献に対する気づきを多数アドバイスいただき、この面でも学ぶことができると考えています。 また、通学が可能な範囲、学費の面での国公立の大学という諸条件も九州大学は満たしており、受験を決めました。

博士後期課程に向けての準備など

九州大学大学院システム情報科学府では、社会人特別選抜試験が用意されており、こちらを受験することとなりました。 前提として指導教官との受け入れに関する合意が必要ですが、僕の場合、幸い、既に先生と共著で論文執筆する機会があり、その繋がりで指導についてお願いすることができました。

出願について、学士である僕は、修士相当の学力を持つという出願資格を認めてもらうため、事前審査が必要でした。 そのため、以下の出願資格を満たすことを証明する内容と研究実績を事前に提出しています。

(7) 文部科学大臣の指定した者 A) 大学を卒業し,大学,研究所等において,2年以上研究に従事した者で,本学府において,当 該研究の成果等により,修士の学位を有する者と同等以上の学力があると認めた者

事前審査のため、通常の出願スケジュールより前倒しで各種書類なども合わせて準備する必要があります。 僕の場合、2020年10月入学の入試に向けて、5月下旬が事前審査の書類提出でしたので4月下旬ごろから関係書類を集めていたようです。 ここで落ちるようなら、修士から臨もうと考えていましたが、幸いにも出願資格を認めてもらうことができました。 もしかしたらここが一番緊張したかもしれません。

2020年10月入学の入学試験は、口頭試問でした。 これまでの研究実績と博士課程での研究計画に関して発表し、質疑応答という形式です。 限られた時間で3年間の研究実績と研究計画に触れなければならず、羅列ではなくストーリーの中での位置付けと重要な部分の抜粋が必要となり、資料の作成には苦労しました。 それでも、資料作成を通して研究テーマや位置付けの整理が一段階進み、結果として自分の研究とこれからを見直す良い機会になったなあと思います。 せっかくなので公開可能な範囲で資料を公開しておきます。

試験を終えた感想としては、事前審査にしろ口頭試問にしろ、そのために慌てて頑張って準備が間に合うようなものではなく、きちんとこれまで積み重ねてきた実績やその課題設定に向き合ってきた量というのが試されたんだろうなあと思います。 なお、完全に余談ですが、マスクをつけて30分程度の発表と質疑応答は酸欠で倒れそうになったので、今後もこのような状況が続くようであればフェイスマスクのような呼吸が楽な装備をお勧めします。

会社の支援

10月より社会人博士課程に挑むことになりますが、所属する研究所において、業務との両立について理解をいただけています。 特に、博士課程の研究テーマにサービスの改善に適用可能なものを選択したことが理解を得やすかった点だと思います。

これから

研究としては、今取り組んでいる推薦システムの自律適応について発展させていきたいと考えています。 シラバスを見る限り、博士論文に向けて色々指導の時間(指導教官以外の取り組む研究テーマの分野ごとの研究指導や関連研究調査など)があるようで、研究そのものの発展はもちろんのこと目的としている研究力の向上も図れるのではないかなと、今から楽しみです。


ペパ研から研究をはじめてジャーナルでのアクセプトまでいけた日

先週の6/22、初めてジャーナルの採録通知をいただいた。

大学は情報系ではなく、大学院にも行っていないので、研究なるものを始めたのが、ペパボ研究所に入った2017年1月から。3年半もかかってしまった。

元々、サービスの運用開発をしていた経緯もあり、2017年の前半はその延長で研究報告を2本書き切った。 初めての研究報告は、論文の型みたいなのを徹底的に教えてもらえた。 今も執筆時に気をつけるところのほとんどはここで教えてもらったことが根底にあると思う。 2017年の後半から、研究の内容自体も「すごいもの」にしようとした結果、迷走が始まる。 自分のやってきたことを深堀するわけでもなく、先達の研究を調べるわけでもなく、自分の能力を高めるわけでもなく、ただ、目新しいことに挑んでは当然のように跳ね返され、焦りから近道を探し、悪循環に陥る。 研究所内で、(今にして思えばほぼ八つ当たりな)相談したり、WSA研でいろいろな人の研究に対する考え方を聞きながら、自分の中の蓄積や道標をきちんと整備していかなければと考えるようになった。

2018年は、アドバイス制度を利用して初めてジャーナル投稿に挑戦した。 当時としては全力で取り組んだ論文はあらゆる直接的間接的な表現で「よくわからないです」とアドバイスをいただき、心砕け撃沈した。 まだまだ付け焼き刃な研究は、専門性に対する脆い知識や理論構成であり、指摘に対して一気に瓦解する。 やれることは、専門性を高めることだけなのだが、分野のあまりの広さ・難しさに途方に暮れていた。 この時期は、指摘をまだアドバイスと見なすことができず辛い時期であった。

2019年の前半は、転換の兆しが見えたが苦しい時期でもあった。 わからないなりに勉強を続け、サーベイを進めた。 自分なりの方向性を見つけ、評価し、効果がある研究ができた。 それでも相変わらず研究報告を上手く書けない。 文章として形が見えていく中で、新しい前提や課題が明らかになり、議論は活発になる。 当たり前のことであり、むしろ喜ばしいことであるのだが、どこかで形を決めなければならない。 この時期は、これは、もっといけるはずだという期待に応えたい気持ちとそれを時間内に解決できない自分の無力感で悪循環に陥ることが多かったのではないかと思う。 そして、この時期の振り返りで、自分と向き合った結果、「結局は、無能だと判断されたくないだとか、集中することができれば大きな成果を出せるはずだとか、心の奥底に対外的な評価が中心に据えられて、自己評価とのギャップと相まって動けなくなっていたことが原因だと思い至」った。

2019年の後半、これを踏まえ冷静になりつつ、いろいろな人に助力をいただきながら、前に進んだ。 学術系ではないがGo言語の国際カンファレンスのトークセッションに採択された。 ポスターセッションではあるものの学術系では初めて査読ありセッションで採択された。 ジャーナルへももう一度挑戦した。結果はリジェクトであったが、査読者の判定は、条件付き採録と不採録で別れ、メタ査読者からは前半(研究の前提や既存研究に対する位置づけ)は非常に読みやすいとのコメントをいただけた。 後半の提案手法やその評価について、アーキテクチャ含め更新、年内にまた別のジャーナルに提出へこぎつけた。

2020年、3月にその論文が条件付き採録となり、これに応えて晴れて採録通知を受けたのが先週。 「ペパ研から研究をはじめてジャーナルでのアクセプトまでいけた日」は研究所の所長が言ってくれた。 本当にそうだなあとこれまでのことを思い返して、泣けた。 今にして思えば遠回りばかりして、勝手に袋小路に迷い込んで非効率極まりない反面教師の塊だと思うけれどもこの過程と振り返りがなければ、今の研究もできていないだろうし小さな人間のままだったかもしれない。 これからまた難航することがあるかもしれないが、今はこの経験が今度は乗り切れるのではないかと思わせてくれる。 なんにせよ、自分のような人間が、ジャーナルを通せるところまでたどり着くことができたのは、ひとえに見捨てずに見守りアドバイスをくれ、相談に乗ってくれる周りの方々のおかげです。 遠回りばかりしていますが、これから、改めて巨人の肩に乗ることから逃げずに真摯に向き合い一歩づつ精進していこうと思います。


今年は他にも、研究チームとしての側面も取り組んで、研究報告ではあるが、はじめて2本ラストオーサーを務めた。 研究所での論文読みや勉強会などの新しい習慣も定着し、今後が楽しみ。 また、自身の研究も前進させ、ジャーナルのアドバイスもうまく取り込めていると思う。 国際会議なども狙っていきたい。 そして、博士課程に挑戦することにした。 まだ結果はわからないが、これまで模索してきた取り組みを加速できると良いなと思う。

過去の振り返り

Go言語でシミュレーション用のシンプルなフレームワークStageをつくった

時系列に対するコンピュータシミュレーションを開発する機会が増えてきたので、共通する処理の流れをフレームワーク化した。

コンピュータシミュレーション

状況に応じたクリック数の最大化や変化点検出のような、システムの適応的な振る舞いを検証するために、時系列に対するコンピュータシミュレーションを行うことがある。 また、実環境で発生するランダムな誤差を表現する場合、乱数を用いたシミュレーション技法であるモンテカルロ法も利用することになる。

このようなシミュレーションのプログラムでは、変化する時系列を入力に、振る舞いのシミュレーション結果を出力するだけではなく、乱数によって発生する誤差を均すためにシミュレーションを数百〜数千回繰り返す必要がある。

Stage

Stageは、これらの一連の流れの実行とこれに伴う煩雑な処理(シミュレーションの並列化、乱数の管理、進捗の監視、ログ出力)を開発者から隠蔽する。 開発者は、時系列や振る舞い、ログフォーマットをGo言語で記述するだけで良い。

Stageで行っているメイン処理の「疑似コード」は以下の通りシンプルである。

for i := 0; i < iter; i++ {
    sem <- struct{}{}

    go func() {
        scenario := NewScenarioFn(rnd.Int63())
        actor := NewActorFn(rnd.Int63())

        for scenario.Scan() {
            action, _ := actor.Act(scenario.Line())
            w.Write(action.String())
        }
        <-sem
    }()
}

このフレームワークでは、メタファーとして劇場(Stage)を採用した。 劇場は、劇を開催する。 その劇は台本(Scenario)があり、演者(Actor)は台本の1行づつのセリフ(Line)に沿って演技を行い、結果(Action)を出力する、といった形だ。 そして劇は何度も繰り返される。

開発者は、時系列や振る舞いをそれぞれ、ScenarioとActorのinterfaceを実装によって記述する。 また、ログフォーマットもAction interfaceで指定するだけで良い。

type Scenario interface {
	Scan() bool
	Line() Line
}

type Actor interface {
	Act(Line) (Action, error)
}

type Action interface {
	String() string
}

あとは実装したScenarioとActorを生成する関数を指定して必要な回数実行。

dir := "log"                    // Directory for output
concurrency := runtime.NumCPU() // Number of concurrency for scenario
seed := 1                       // Seed for random
iter := 3                       // Number of iteration

s := stage.New(dir, concurrency, seed)
s.Run(iter, NewActorFn, NewScenarioFn, stage.NoOpeCallbackFn)

結果は、指定したログディレクトに出力され、実行日時や利用した乱数シードも確認することができる。

log
└── 20200530184234-1 # Timestamp-Seed
    ├── iter_00-a_7947919477105006377-s_5355116748216652230.log # Iteration log files
    ├── iter_01-a_4846631296614585111-s_2007235010091403794.log #   with seed for actor(a)
    └── iter_02-a_0610076349056253918-s_3540139325796113853.log #   and  seed for scenario(s)

なお、出力後の解析、グラフ出力については、Stageでは取り扱わない。 任意のフォーマットで出力できるのでお好みの言語やツールで操作して欲しい。

各インターフェースの具体的な実装方法についてはREADMEを参照のこと。

複数のシナリオを持つシミュレーション例

例えば、以下の青線のような変化の仕方が異なるシナリオを切り替えて、橙の線のような振る舞いの違いをシミュレーションすることができる。

Abrupt changesGradual changes
example_adwin_abruptexample_adwin_gradual

長時間かかるシミュレーション例

また、シミュレーションに時間がかかる場合は、各シナリオの完了時に呼ばれるCallback関数を指定することで、進捗の監視もできる。 お好みのProgress barライブラリを使えば進捗バーも表示できる。

$ go run _examples/progress/main.go
180 / 200 [---------------------------->___] 90.00% 40 p/s

まとめ

普段よりアルゴリズムの理解を深めるため手に馴染んだGo言語で実装を試みるので、必然的にシミュレーションもGoで書くことが多くなったことからGo言語での実装となった。 完全に自分用途でつくったフレームワークではあるが、各シミュレーションにおいてシナリオとアクターという要素のみを意識すればよくなり実装の効率が格段に上がりコードの見通しもよくなった。 また、Go言語を使うことで並列化が容易に実装できシンプルなフレームワークでありながら十分に安定して高速化を達成できていると思う。 付加的な利点として、ログ構成などが統一されたことで後段の解析やグラフ化のスクリプトも共通化が進んでおり、個人的に満足度が高いものができたと思う。

Archives