きっと大丈夫、って、ほんとに大丈夫？

きっとうまく行く、きっと大丈夫、という言葉は胡散臭いと思うけど、ある意味合ってるとも思う。でも、言葉足りずだと思う。

僕は経験上、難しい問題（特に人間性とか曖昧なもの）は、すぐ解決するものじゃなかった。ゆえにずっと解決しないのかなと自分が感じて絶望したもの。そして苦しむ。
ただ、同時に僕の経験上、そういう難しい問題は絶対に解決しないわけでもなく、適切な助言者や手助けを借りて適切な努力をすることによって解決する場合がある。ただ、この解決するというのは、時間がめちゃくちゃかかるものと思った方が良い。１年、３年、下手したら５年１０年を超える。でも、ずっと解決しないわけではない可能性がある、この点が重要。

そもそも、人間性や曖昧なものを解決するには、その曖昧なものをブラッシュアップし鮮明にする必要がある。この鮮明にするというのが本当に時間がかかる。学校の数学や物理の問題であれば、既に答えと説明が用意されていて理路整然と説明可能である。それに対し、自己肯定感の低下やコミュニケーションの苦手といった悩み、ソフトスキルといった能力的な話などには答えがはっきりせず、難しくて問題文すら曖昧な問題である。

有効な問題解決には明確な問題提起が必要なのだが、それが難しいのが性格・感覚などの絡む曖昧な問題。賛否両論の類も難しいだろう。そのような問題を解決するには、曖昧さの除去が必要でそれにまぁ時間がかかる。それゆえ、ずっと解決しないんじゃないか、と思って絶望することがあるのだ。僕の経験則では（統計的ではなく信憑性がないかもしれないが）、僕の経験上でそういった問題の解決には、曖昧さの除去含め大体数年以上かかる。それで、一部の辛いことや悩み事はすぐ解決しない。

それに加え、答えがない問題は試行錯誤の連続であり、問題がはっきりしても、その解決方法も自分で模索する必要がある。この時、何回も失敗するだろう。「解決策A」を試して全くダメで、次に「解決策B」を試してまたダメ... という具合だ。なんなら、解決策Aで正しかったのに、ちょっとミスって失敗しただけで、解決策Aは間違ってると誤認にしてしまい空回りし出すこともありえる。コンプレックスといった他の問題が邪魔して挫折することもありえる。そのため、自分に関するあらゆる事情が絡むことから、自分に最適化されまくった答えを探す必要があり、一般論的な答えが通用しないのだ。

したがって、問題をはっきりさせた後もまた、数年かかる要因として解決策の模索期間がある。だから、すぐ解決しないのだ。

...

といっても、問題はずっと解決しないんだ、と感じて絶望を盲信し諦めることは危ない。この点を克服して、きっと３年か５年、それか１０年後、うまくいく、と信じることができれば、まだ絶望は控えめで、必要な問題解決のための対策を円滑に進めることができるのではないだろうか。

だからこそ「きっとうまく行く」「きっと大丈夫」、そういった一見すると中身のない言葉は、数年後、５年後、１０年後といった長期スパンで、いつか解決するから安心してほしい、というように受け取った方が良いかもしれない、と僕は思ってる。

（受け取りようの問題で絶対とはいえないが）

Windowsっぽい、PC的な表現について、事例紹介

そういえばなんか、数年前からWindows風動画が増えた気がする、MVで。なんなら古いPC画面をぶっ壊すような演出、徐々にマイナーな界隈からメジャーな界隈に出てきてる気がする。ぶっ壊すってのは、ウィンドウが大量発生、文字化け大量発生、ウイルス大量発生、みたいなノリの表現のこと。これは元々、MADで見受けられたような表現だったようにも感じている。（実際のところどうかはわからないけど。）

というのも、直近に星野源さんが出したGlitchってMV、まさにって感じの演出が使われていた。紅白で登場するくらい有名な人も使う演出として普及するとは僕は思ってなかった。

youtu.be

以前からGlitch以外の創作物でも「PC画面風の表現、よくMVで見るな」と感じてたから、PCの表現があるグリッチって感じの創作物の事例を今日は紹介したいと思う。なお、ここではパソコンの画面のような表現のことをPC表現と呼ぶことにする。

Windows MAD

僕が昔いじってたWindows XPマシンのBSOD

まず最初に、WindowsのMADを紹介したい。それはウイルス感染のような様子を表現する、MAD動画のジャンル。 以下のような表現が多用される

• ウィンドウが溢れる（特にエラーダイアログや質問ダイアログ）
• ブルースクリーン（OSのクラッシュ時の画面）を表示する
• Windowsの効果音を使って音楽を奏でる

まぁ盛大にエラーになって音楽まで演奏している状況を面白おかしく楽しむやつやね。まずはこの事例を紹介する。

これは、体感だとネットミームオタクが知ってる可能性があるくらいのマイナーさ。大学の友達に聞いても、学部・学科にもよるが知ってることは低確率だろう。 僕がこのWindows MADを使った演出として最初に出会ったのは、元はと言えば「【Windows】RED_ZONE.exeが本気を出したみたいです」が始まり。（厳密にいうとScratchにある再現プロジェクト。） 僕は小学生の頃がっつりこれにハマってしまったよ。（厨二病）狂ったようにこれ系の動画を漁った。

www.nicovideo.jp

youtu.be

youtu.be

これ、軽く１０年は前の動画があるような古いMAD。でも僕がこれにハマってたのは2015年か2016年ごろ、僕は2005年に生まれたからリアタイではみていない。

ウィンドウを沢山出したり、エラーメッセージを出したり、それがかっこいいとか、面白いとか、このネットミームジャンルは様々な感情を生み出した。そしてそれを生み出す特徴があった。 この表現力はMAD以外の創作物でも有用さがあると感じられ、もしかして、PC表現の源流の一つとしてWindows MADがあるのでは？

余談: ブラクラ

ウイルス・エラー系の演出でいうとPC画面全体ではなく、その中の特にブラウザにおける「ブラクラ」に着目した演出もあったりする。ブラウザクラッシャーの略で、ブラウザ（なんならPC自体）を激重にして処理落ちさせてくるウェブページのことをブラクラと呼ぶ。（これは厳密にはウイルスではないとする人もいて、エラーでもない。）

このブラクラの一種「You Are An Idiot」が元ネタとしてよく使われることで有名。詳細はこのゆっくり動画がわかりやすい。 月ノ美兎さんがそのブラクラのパロディを投稿している。そしてこのYou Are an Idiotの演出はGlitch内でも使用済み。

youtu.be

ゲームでの表現

ゲームでのPC表現というと、割とありふれているが有名なものをここでは紹介する。それはドキドキ文芸部とNEEDY GIRL OVERDOSEだ。

前者に関しては2017年くらいに発売されて結構昔に出てきたのだが、あのゲームは少しメタい演出がある。あのゲームがRen'Pyで実装されているのもあってか、Pythonのエラーメッセージを表示することがある。（他にもメタいPCネタはあるが、ネタバレになるので割愛。）

後者に関して、僕が高校生中盤くらいの頃からNEEDY GIRL OVERDOSEが流行り始めた。これはかなり流行ったのがわかりやすく、僕の友達や知人がどちらかというとファンよりだったのを知って驚いた。グッズを買ったりしてた。このNEEDY GIRL OVERDOSEはUIがレトロPC（Windows 98あたり）風を採用しているなど、モロPC画面を演出に使ったゲームとなっていた。

（もっとゲームでの表現はあると思うが、時間がないので、いつか追加したい。）

ボカロでの表現

ボカロのMVではかなり見かける。以下の通り。

youtu.be

youtu.be

youtu.be

youtu.be

youtu.be

youtu.be

youtu.be

最後の「花弁、それにまつわる音声」はうーん良い。エラーアイコンが沢山。怖い絵文字も評価高い。（小並感）

VTuber

VTuberが採用していたりもする。これに関しては、ゲーミングPCとかChatGPTとか、ITリテラシーの高まりによる親しみ向上とか、昨今の情勢が影響していそうな気もする。

youtu.be

youtu.be

余談: PCをキャラクターがぶっ壊す演出

Caramel Painのような、PCをキャラクターがぶっ壊す系の演出といったら語らなければならない人がいると思ってる。アニメーターのAlan Beckerさんだ。

僕は小学生の頃、これら映像に見惚れた。ぜひこれらの作品も、PC表現が好きならみておいて欲しい。

youtu.be

youtu.be

youtu.be

youtu.be

youtu.be

Minecraftのやつに関しては、PCとMinecraftの両方が好きだった僕にとって、たまんないものだった。

おわり

PCがニッチだった頃にMADで使われてたエラーなどのPC表現が、いまはすぐそこに！僕はこの凄みというか、驚きをぜひとも紹介したくこの記事を作ったんだ。 もっと他にもPC表現を使ってる創作物があった気がするが、すぐ思い出せないので、思い出したりしたら追加したいと思う。

この記事を読んでくれてありがとう！

Chromiumの並行処理モデル

注意: この記事について

この記事は、cfredric氏が作成したスライド "Concurrency in Chromium"の内容を日本語に意訳し、ブログ形式に再構成したものです。この記事で使用した画像も、元スライドにあった画像を使用しています。

日本語での理解を優先し、私なりに補足や構成の変更を加えているため、原文の逐次通訳ではありません。そのため、内容のすべてが必ずしも原著作者の正確な意図を反映しているとは限らない点をご了承ください。

Chromiumの並行処理モデルに関する直感的な理解を深める一助となれば幸いです。

Chromiumにおける並行処理

Chromium は安定性・機密性・速度のために複数のプロセスを使って稼動するアプリケーションである。 そしてそのプロセス一つ一つは、以下のようなスレッドにより構成される。

• メインスレッド （ブラウザプロセスではUIスレッドとも呼ぶ）
• IO スレッド （注: IPCのためであって、ファイル／ネットワーク用ではない）
• その他、何かしらのための専用スレッド
• 汎用のスレッドプールのスレッド

これらからわかるに、Chromiumの処理はかなり並列化されている。多くのプロセスやスレッドらが同時並行・並列的に動くため、これを安全かつ正しく処理する必要がある。

また、Chromiumにとってスレッドというのはとても重く粒度が荒いことも問題といえる。抽象的なレベルで説明すると、Chromiumは多くのワークストリームを持ち、これらが多くの場合独立していて並列化が可能だ。つまり、私たちが本当に求めているのは、これら作業ストリームをスレッド間でいかに負荷分散するか、という点である。

ここでは、従来の並列処理手法とChromiumが採用する手法、そしてどのようにそれを扱っていてかつ安全・適切に実現しているか、そしてそれをどのAPIを通じて使用できるのかを説明する。最終的なこの記事の目標は以下の通り。

• Chromiumの並行処理モデルに関する直感的な理解を提供する
• Chromiumにおける並行処理の扱いに関する有用なヒントやコツを示す

（一般的な）プロセス内並列処理

同時並行・並列処理を「安全かつ正しく処理する」とは一体なんなのか。もし私たちがこれに注意しない場合、きっとスレッド間のデータ競合が発生してしまうだろう。プロセスにおける様々なスレッド群は同じメモリ空間にアクセスすることができ、ゆえに私たちはスレッド群がお互いに邪魔しあわないよう協調させる必要がある。

一般に、この課題に関してはいくつかの解決策がある。まず一つが、ミューテックスや条件変数、セマフォ、バリア、そしてその他プリミティブを使うことである。これにより複数のスレッドは同じデータに対し書き込みなどのアクセスが可能になる。このアクセスが同時に二つ以上から行われることはない。これは古典的な手法で私たちの多くが多分親しみがあるだろう。この手法のキャッチフレーズは「記憶を共有することでやりとりをする」といえる。

それ以外のアプローチとしては、データをスレッド間で送るためにコミュニケーションプリミティブを使う、ということが挙げられる。つまり、一度に一つのスレッドしかデータを持たないということだ。この手法のキャッチフレーズは「やりとりをして記憶を共有する」といえる。

もちろん、これらのアプローチは互いに排他的ではなく（つまり、競合しない）、それらを組み合わせてハイブリッドな手法を用いることができます。

Chromiumでのプロセス内並列処理

前述したハイブリッドなやり方をChromiumは採用している。そして、メッセージパッシングの手法を強く推奨している。かといって、もし必要であればミューテックスなどのプリミティブも使用するが、ほとんどの場合に使用されない。

この、ハイブリッドを好みミューテックスなどをあまり使用しない理由は、ロックという処理はオーバーヘッドを少し生むためである。Chromiumは大量の並列処理を行うが、その並列に行われる処理のほとんどは、実際のところ同じメモリにアクセスする必要がない。このため、ロックの処理は無駄に近い。よって私たちはできる限りロックを避けることが多いわけだ。

Chromiumの並行処理における語彙

さて、これまで、一般的な並列処理手法とChromiumがその一般的な手法をハイブリッドに採用している、ということを説明したが、当初のChromiumの目的というのはChromiumの持つ多くのワークロードをどう分散するか、という点だ。これを説明する前にChromiumで使われる語彙を予め説明しておく。

• Task: 基本的な処理の単位、スレッドで実行可能
  • 具体例としてOnceCallbackやRepeatingCallbackが挙げられる
• 物理スレッド: OSスレッド、OSにより管理されるスレッド
  • 例: POSIXのpthreads
  • Chromiumでは恐らく、これに直接やりとりする機会は少ない
• base::Thread: クロスプラットフォームな物理スレッドの抽象
  • これも、基本直接触ることはあまりない
• Sequence: 仮想スレッド／ワークストリーム
  • Chromiumではワークストリームの代わりにシーケンスと呼ぶ
  • 特定の物理スレッドとは紐づかず、基盤となる物理スレッド群のいずれかで処理される
  • 順序通りに処理するタスクのキューを持つ

なお、Chromium の開発者として base::Thread を使用することはまずないだろう。代わりに base::ThreadPool を使用するのが好ましい。

Chromiumのシーケンス処理方法

基本的な語彙を説明したところで、Chromiumのロードバランシングの実現方法をみていこう。以下にいくつかのアプローチが列挙されているが、最後の一つがChromiumで有効なものだ。

• ❌ １つのスレッドと１つのシーケンスを紐づける
  • シーケンス毎に一つのスレッドを作る
  • → シーケンスは大量にあり、大量のスレッドが作成されオーバーヘッド
• ❌ １つのスレッドと複数のシーケンスを紐づける
  • スレッドはシーケンスの集合を持ち、それらを処理する
  • → 一つのスレッドじゃ負荷分散ができない
• ✅ 複数のスレッドが複数のシーケンスを処理する
  • スレッド群はシーケンス群を共有し、次に実行するタスクをスケジュールする時、シーケンスを一つ選び、そこにあるタスクを処理する
  • → シーケンスを忙しいスレッドから暇なスレッドに移動でき、負荷分散が容易
  • → スレッドを大量に作る必要がない（低スペック端末にやさしい）

最後のが一番効率的にタスクを処理することができ、負荷分散ができることがわかる。

シーケンスを安全に使う方法

効率的に処理をする方法をスレッドとシーケンスの数の関係で説明したが、次は安全な処理方法について説明する。

二つ以上のスレッドがデータにアクセスする時にデータ競合が発生しうることと、シーケンスから得たタスクは一度に一つのスレッドでしか実行されないこともこれまでに説明した。ここからわかるに、もしも特定のデータにアクセスする全べてのタスクが同一のシーケンスに属するならば、一度に実行されるタスクは一つであり、そのデータに関しては競合が発生しないといえる。

そして、これがまさに SEQUENCE_CHECKER を使う理由であり、これは GUARDED_BY_CONTEXT マクロを使用して、常に同一シーケンスからアクセスすることを保証するものである。一般に、ほとんどの Chromium コードでは単一スレッドではなく単一シーケンスを使っても、データ競合の観点で問題がない。さらに、単一シーケンスを使用するようにコードを記述することは、単一スレッドよりも柔軟である。なぜなら、シーケンスは任意のスレッドで実行されるため、より優れた効率の良いスケジューリングに繋がる可能性を持つからだ。

ちなみに、ThreadChecker という、メソッドが同じスレッドから呼び出されているか検証できるものがあるかが、これは物理スレッドを考慮することとなり、単一シーケンスを使うことはこれより柔軟性がある。

シーケンスの概略図

この図は、Y軸が別々の物理スレッドを表していて、X軸が時間となっている。オレンジの箇所がシーケンスである。

オレンジ色のシーケンスは二つの別々の物理スレッド上で実行されていて、なおかつ任意の時点でシーケンスを実行しているのは一つの Worker スレッドのみとなっている。GetHistory タスクは UI スレッドから追加された順番通りに実行されていることがわかる。

シーケンスの内部

ここで、私たちにとってシーケンスがどう動いて欲しいのかについて、洞察をいくつか説明しよう。Chromium がどのように処理をこなすのか知るため、少し実装詳細を覗いて見ることにする。

• Sequence クラスは TaskSource を継承する
  • TaskSource: タスクのストリームを提供する
• Sequence クラスは、以下を持つ
  • SequenceToken: 整数をラップした、シーケンスが持つ一意のトークン
  • SequenceLocalStorageMap: スレッド局所記憶（TLS）の Sequence 版

概念的には、シーケンスはタスクを順番に実行するキューと考えることができる。それ以外の部分では、操作を実現するための配線と意図した通りに動作したことを保証するメタデータにすぎない。より具体的にいうと、シーケンス（Sequence）はスケジュール基盤のための TaskSource であり、なおかつ SequenceToken という一意の識別子を持つ。

次に、もう一つ重要なことがある。もし複数のスレッドを扱う時、スレッド局所記憶という概念がある。全てのスレッドが同じアドレス空間を共有しているにも関わらず、各スレッドが自分専用のメモリを持つことができるものだ。Chromiumも同様に、シーケンスに対して同じ概念、いわば"シーケンスローカルストレージ"をサポートしている。このデータを格納する場所が、SequenceLocalStorageMap といえる。

インフラがシーケンスを使う方法

これまで、多くのシーケンスが存在する目的とその用途・実装概要を説明したが、これは実際にどうインフラで使用されているのか、をここで説明したい。

厳密な答えは複雑になるが、要点は次の通り。スケジューラは特定のシーケンスにおいて同時に実行されるタスクが一つになることを保証する。そしてシーケンスからとったタスクをスケジューラが実行する前に、SequenceToken と SequenceLocalStorage をスレッド局所記憶に格納する。つまり、各スレッドは「現在実行中のシーケンス」を示す識別子を持つ、ともいえる。

これにより、処理で必要なものが大体揃う。これにより得られるのは、相互排他を保証するために以前使用したプロパティと、実行時に SEQUENCE_CHECKER を使った相互排他の検証をするのに使うメタデータである。

何がシーケンスを作る？

シーケンスが有用なタスク処理のための抽象であることを知れた今、ではどうやってこれを使うのか。答えは基本作成しない。厳密にいえば、少なくとも、直接的には作成しない、ということだ。

• シーケンスは ThreadPool / TaskRunner の基盤により連携することができる
• シーケンスは以下により自動で作成される
  • base::ThreadPool::Post[Delayed]Task
  • base::Create[Updateable]SequencedTaskRunner
  • base::CreateSingleThreadTaskRunner

Chromium のタスクスケジューリング基盤は、シーケンスを必要に応じて自動で作成する。 例えば、ThreadPool::PostTask を呼び出したとする。これは、特に他タスクとの実行順序に関する保証を特に要求しないため、呼び出す度に新しいシーケンスを作る。

同じように、Sequenced または SingleThread な TaskRunner を作った場合、これらは作成する新しいシーケンスと紐づけられるだろう。

どう自分のシーケンスから別にタスクを送る？

そしたら、沢山の Chromium コードが特定のシーケンスで適切に処理がされているかをチェックしている最中、どうやって自分のコードを別のシーケンスで安全に実行させれば良いのか、次にこれについて述べる。

これをするには、タスクをシーケンスに対して「ポスト」する必要がある。そのために以下の選択肢がある。

• 任意のシーケンスで良い場合: ThreadPool::Post[Delayed]Task
  • 新しいシーケンスが作成される
• 特定のシーケンスがいい場合: SequencedTaskRunner / SingleThreadTaskRunner の Post[Delayed]Task
  • 使用タイミング: サードパーティ製ライブラリがシーケンスに対応していない場合、スレッド局所記憶を使用している場合

また、シーケンスでのやり取りをする際に便利な機能として、SequenceBound<T> があり、これはメソッドやコンストラクタ・デストラクタを特定のシーケンスで呼び出すのに便利だ。

どう自分のシーケンスの管轄でタスクを扱う？

もし今動いてる自分のシーケンスからタスクが離れて帰ってこないことがないよう、実行したいならどうすればいいかも、触れておく。

• タスクを別シーケンスで動かし、終了時に自シーケンスで処理をしたい場合
  • TaskRunner::PostTaskAndReply[WithResult]
  • ThreadPool::PostTaskAndReply[WithResult]
• 自分のシーケンスで非同期的に動かしたい場合
  • base::SequencedTaskRunner::GetCurrentDefault()¹
  • SequencedTaskRunnerHandle::Get()->Post[Delayed]Task（昔の手法）

コールバックに関する文書: https://chromium.googlesource.com/chromium/src/+/main/docs/callback.md

どのシーケンスで動かせばいいかわからない

最後に、Chromium の大量のコードに当てはまるくらい重要なこととして、実行すべきシーケンスが決まっていない場合、基本的には特にすることはない。内部で暗黙的にシーケンスを処理してくれるからだ。

例えば、Mojo は内部でシーケンスを処理するため、Bind が呼び出されたのと同じシーケンスに対して Mojo レシーバーメソッドが呼び出される。Chromiumの色々な箇所で、シーケンスを扱っている実装が既にある、ということだ。

参考資料

• Threading and Tasks in Chrome
• Threading and Tasks FAQ
• Share Memory By Communicating - The Go Programming Language
• The Chromium Chronicle #1: Task Scheduling Best Practices
• Chrome U 2019: Life of a Process (slides)
• Callbacks in Chromium

付録

• Jobs (post_job.h)
  • パワーユーザー向けのAPIで、大量な処理が必要な人向け
  • タスクスケジューラのオーバーヘッドが顕著になった場合に使用可能

---

1. この記事の元となったスライドにはないが、これは SequencedTaskRunnerHandle がなくなった後の新しいやり方であるため、ここに追加した。↩

データの扱い方に関する課題と新しい方向性

この世界は現在、急速に情報社会が発展していて、今この時も情報が増え続けている。（下図）そして近い未来、現在よりも膨大な情報を活用したプロジェクトを行うようになるだろう。しかし、膨大な情報を人間が直接処理することは現実的に不可能であり、むしろこれからはいかに情報を捌いていけるかが情報社会における主要な課題となるだろう。そこでこの課題を解決すべく、将来的にパッケージマネージャのエコシステムを用いたコンピュータシステムが開発されると私は考えている。また、そのシステムを活用することで、複雑な情報を効率良く適切に捌き、健全性を保ったまま情報を扱う仕組みを構築することができるはずである。

喜連川優「情報爆発のこれまでとこれから」,電子情報通信学会誌,Vol.94,No8,2011

まず、前述した課題が将来どう生じてしまうか考えてみた。情報は様々な場所で利用されており、それは扱う上で我々にしばしば何かしらの制約を課す。例えば数学の証明の場合、イコールには両辺を同じにするという制約が生じ、その制約のもとで証明を成り立たせることができる。情報を扱う上でも同様のことが云え、その制約は保守する必要があり、そうでなければ破綻してしまう。しかし、その制約自体、将来的には人間が保守するものではなくなると私は考える。なぜなら、情報が増え続ければいつかは人間が把握しきれない量となり、前述した制約の検証が情報全てには行き渡らなくなるからだ。そうなると、未来では情報が適切に検証されている保証がなくなってしまい、その情報によって生みだされたものの健全性が欠けてしまい、情報を扱うことが困難になってしまう。そこで、コンピュータを使った情報を健全性を保ちながら効率的に捌くシステム、いわば基盤が必要となってくるだろう。

「情報」という概念は抽象的であり具体例は幅広く膨大に存在する。そのことから、基盤の開発のためには、コンピュータがそれら具体例全てを扱うために情報を抽象化する必要あるだろう。私は、その基盤としてパッケージマネージャにおける依存関係のパラダイムが応用可能であると考えている。なぜなら、その依存関係はまさに情報の制約を検証するための仕組みだからだ。パッケージは情報とみなすことができ、それを扱う上でのバージョン等の衝突防止は制約とみなせるのである。また、依存関係はパッケージの繋がりを記録するためのものでもある。それは情報の関係性を示すものだ。ゆえに、パッケージマネージャは情報を扱う基盤の具体例といえる。そこで私は、パッケージマネージャをより抽象的にした、いわゆるデータマネージャという基盤を作ることで、冒頭にて述べた課題を解決することができると考えている。また、前述した以外にも、データマネージャは以下で取り上げるような様々な場面でも活用されると考えている。

データマネージャは合理的に情報を管理するものであり、“情報の依存関係”に欠陥がないことを保証する。これは様々な理論の展開に応用が可能で、例えば教育の現場でも応用が可能だと考えることができる。学校で学ぶ数学では、四則演算といった将来の学習に必要な知識を前提とした学ぶ。これは教育内容という情報の依存関係として捉えることができるだろう。そのように考えれば、前提知識を含む情報をピンポイントに整理および出力する教育ツールとしてデータマネージャは応用が可能だ。また、生成AIの思考を解析することが困難であることに関して、データマネージャを生成AIの学習モデルと連携することで、思考を解析できるのではないかとも考察する。元来、情報は抽象的なものであるため、前述したこと以外にも応用可能なことは多くあると考えられる。これはデータの活用方法の新しい方向性であるといえるだろう。

このように、データマネージャを活用することで、将来的にはデータは柔軟性に富み、かつ隅々まで取り扱えるようになり、人間社会の多岐にわたって世界の合理化を進めるものとなるだろう。しかし、単純にそれは良い面だけではないと考えられる。隅々まで依存関係を明確にするという行為は、“理論的に全ての情報をまとめる”ということであり、それは森羅万象をまとめる行為に近しい。それは“理論的ではない事象を否定すること”であり、感情論といった人間的なものを追放するものと思われる。今後実現しうる情報社会は、こういった倫理的な問題も引き起こすと推察され、データマネージャを適切に扱うには全人類への理解を図った上で法整備などの社会的な体制を整えていく必要があると考えられる。もし私が考えるデータマネージャが実現したのなら倫理的観点も視野に入れ、社会に受け入れられるものとなるよう十分に検討していくことが新たな課題となるだろう。 

---

この文章は高校３年生の時、第三志望の大学進学の際に提出する予定だったレポート。ただ、滑り止めで第一志望が受かったので、このレポートは提出をすることはなかった。だからとりあえずここに書き残してみる。 ちなみに、ここで述べるデータマネージャとまではいかないが、知識管理には昔から関心があるからここで述べたナレッジAIブラウザも思いついた。

ちなみに、昔のウェブサイトにあったブログに投稿していたが、ウェブサイトをリニューアルした際にブログをしずかなインターネットに移行していた。 でも、結局、記事系は全部はてなブログにまとめることにしたから、ここで再投稿した。

自分の意見は常にエゴである可能性を持っている？

「死にたい」に対して「死んでほしくない」という人が、「それってお前のエゴだろ、私の気持ちをわかってもいないのに」と言われることもある。僕はこれがごもっともだと思う。というか、僕にもそういう時期があったし、実際ある程度エゴだと思っている。 かといって、「死んでほしくない」って言葉が仮にエゴだとしても、死んでほしくない人が思う「死にたい」もある意味エゴと捉えることができなくもない、なんて。

エゴに対しては大体、相反するエゴが存在すると思ってる。 世の中にはあらゆる意見があって、

• 「自殺はすべきではない」
• 「自殺はしてもいい」
• 「安楽死マシンは導入すべき」
• 「安楽死マシンは導入してはいけない」
• 「たい焼きはみんな食べるべきだ」
• 「たい焼きじゃなくてたこ焼きを食べるべきだ」

みたいに、ある意見があればそれの反対意見も容易に存在しうる。これら意見それぞれに、それぞれの人・関係者の都合・事情があり、その背景からこれら意見が浮上する。世界は広くて、多様性があって、本当に千差万別の都合・事情がある。それゆえ、意見と反対意見は、両者が互いに相手のいうことをエゴだと思う場合が多々ある。センシティブな話題ほど、そうなる場合がありえる。 ここから考えるに、僕が意見を言ったら、世界のどこかに都合の悪い、反対意見を持つ人がいるのではないだろうか。仮に自分の意見の反対意見を友達が言わなかったとしても、世界中の一人一人にインタビューすれば、高確率で反対意見を言う人が現れる可能性が高い。

したがって、

前提：「ある意見が存在する時、その反対意見が存在しうる」

なんて考えられる。もちろん、どんな意見にも反対意見が絶対あるとまでは言い切れないが、世界のどこかに反対する人がいる場合が可能性としてありえる、とはいえる。 この前提が成り立つとしたら、意見を述べると高確率で反対意見が存在しうる。どんな意見を言っても反対意見が世界のどこかに存在する可能性がある。

ゆえに、何にかしら意見を述べたら、それが世界の反対する誰かにとってはエゴに見える可能性がある、と考えることができる。 だから、僕が意見を言ったら、どこかに反対意見をいう人がいて、その人にとってはエゴとなってしまうかもしれない。どんな意見を言ったところで、世界中のどこかにそれをエゴだと思う人がいるのかもしれない。

よって、自分の発言が誰かにとってのエゴかもしれないから、僕は意見を述べたくなくなる。「それお前のエゴじゃん」と言われちゃ、そこでおしまいな場合が多いから。 難しいぜ。

---

P.S. かといって、この意見を言えなくなる呪いに対するアンサーも、仮説程度にある。「お前のエゴだろ」と言われないように説得し納得させる、自分の考えを広めるということ。どこかの誰かにエゴと言われる可能性があっても、その場にいる人が納得できたならば問題がない場合が多い。そこにいる人さえ納得させるつもりで意見を述べる、という方針。この考えで、エゴと言われることを恐れない身の構え方が作れる、のかもしれない。

ナレッジベースとしてのAIブラウザ

　昨今、情報社会といわれるように、世界において情報は溢れかえっていて、それらの情報を円滑に整理し手の届く範囲に収めるナレッジベースが注目されている。また、最近ではCometやChatGPT AtlasといったAIブラウザが台頭し、自然言語による検索が可能になっている。そこで私は、ナレッジベースとAIブラウザを融合した、ハイパーテキストをナレッジとするAI検索機能付きの、ナレッジAIブラウザを提案する。
　このブラウザは、ナレッジベースとAIブラウザを融合すると述べたが、その二つの参考となる既存ソフトをまず説明する。第一にナレッジベースは、Obsidianがその代表として挙げられ、それはマークダウン形式のテキストファイルや画像を管理およびリンクすることができる。次に、AIブラウザというと、最近は自動操作が注目されているが、ここで融合したい特質はそれではない。ここで注目するのはChatGPT Atlasのブラウザメモリ機能であり、過去に見たウェブページを自然言語で参照できるという機能に注目したい。これは膨大なページ群から都合・文脈にあった情報を引き出すことができる。つまり私は、この二つの、Obsidianのようなファイルとリンクでのナレッジ管理、そしてChatGPT Atlasのブラウザメモリのような引き出し機能を融合したい、というわけだ。
　では具体的にどう融合するか、私はマークダウンに加え、ウェブページのHTMLを自分の必要なページ単位で知識として保存し、そこにAI検索機能を組み合わせたいと考える。現代に溢れている情報にはウェブページが多く含まれ、HTMLはハイパーテキストの形式を採用しており、それらウェブページ群は既にリンクにより体系化されている。また、元来ハイパーテキストとは「思考（非線形）とテキスト（線形）の差」による情報表現の不完全性に対する問題提起が起源であり、思考における非線形記憶作用をメタファするものであると斉藤（1998）は指摘した。ここから考えるに、HTMLによるウェブページ群は完成されたナレッジとしての素質があり、それはウィキペディアにみられるメディア表現から見て取れる。私はこのHTMLの持つ知識表現力をそのまま享受し、非線形の知識群を横断的かつ柔軟に検索できるAIを用いることで、効率的に情報を組織化できると考えた。それが私の考える新しいナレッジAIブラウザである。
　ブラウザで多くの情報を行き来しつつ、膨大に増えていく情報をマークダウンとして知識を記述・構築することは困難である。そこで、既に組織化されたHTML資産をナレッジとした、AIによる知識の引き出しを提供するナレッジAIブラウザを私は提案した。これにより、ブラウザから離れることなくナレッジベースを円滑に構築でき、ユーザーの意図や目的をAIが把握した上で的確な知識を抽出できると私は期待している。

斉藤 孝．情報リンクの基本理念．情報の科学と技術．1998，48(12)，p.670-677.

---

これは、千葉工業大学のソフトメディア研究会での、2025年 津田沼祭で配布した会報 Vol.65に掲載した内容。

僕の心理的システム二極化

最近の僕の中のシステム、二極化してる。 感情的なやつと、理論的なやつ。

大体、理論的なやつが舵を取っていて、感情的なやつの道徳や道義、ポリシーに従って、理論的なやつが僕の肉体を操作している。今書いているのも理論的なやつ。 その感情的なやつのポリシーがなければ、理論的なやつは僕の肉体を操作できない。なぜなら目的がないから。行動の目的は感情的なやつが大体提供する。だから、感情的なやつが目的を作って、その目的を理論的なやつが受け取って肉体を動かす、みたいなアーキテクチャを最近の僕は採用しているようだ。 今僕が文章を書いているのも、その感情的なやつが書きたがっているから、理論的なやつが書いてあげてるに等しい。理論的なやつはいわば、推論・行動エンジンにすぎない。それ自体に人生の生き方だとか、目的はない。

でも、たまに感情的なやつが暴走する。その時は、頭が燃えさかって葛藤して焦っているが、思考だけは冷静。いや、思考が冷静というより、理論的なやつが発する言葉が冷静。思考は暴走の影響を受けるから、多少バイアスがかかってしまうが、理論的なやつが感情の暴走とは無関係であるが故に、理論的なやつの言葉だけは冷静で思考や行動にはバイアスがかかることがある。 理論的なやつだけはいつも冷静で、それ以外は暴走すると文字通り暴走する。

この感情と理論の二つのシステムが、最近の僕では独立して連携して僕を動かしている。なんだかコンピュータみたいで面白い。理論的なやつは、さっき言った通り自律的に目的も目標も作らなくて動かないから、そいつは人間っぽくない。多分、感情的なやつが僕の人間味の大部分を持っている。