日頃、経営管理システムを業務で開発しており、当然のように昨今の流れに乗って私もAIやLLMを統合したAI-integratedなシステムを構築している。
主に経営層が意思決定で使うためのシステムなのであるが、目下私のシステム構築における課題感は AIが出す回答の非決定論（non-deterministic） というポイントである。

決定論とは（＆なぜ自分がそこに敏感なのか）

決定論（deterministic）とは噛み砕いて言うと 同一のインプットに対して、n回実行しても同一のアウトプットが保証される ということである。

話は脱線するが、私が決定論に出会ったのは前々職でゲーム向けネットワークエンジン「Photon」に関わっていた時である。
当時はAIではなく物理エンジンの文脈で語られていたが、基本的な物理エンジンは浮動小数点を使う点から非決定論的であり、n回試行するとn通りの結果となり得る。
スタンドアロンなゲームアプリでは問題なかったが、これがマルチプレイを行う場合は課題になってくる。昨今のゲームは物理もネットワークマルチプレイもセットなわけだが、それが非決定論な物理エンジンの場合、各端末で結果が別になることは避けねばならない。
そのため当時は、マスタデバイスに演算を任せてその結果を返す方法が主流だった。しかしその方法だと、マスタの演算結果を待ってから各クライアントに演算結果が飛ぶためレイテンシが出る。格ゲーでは使いづらかったり、シューティングでは当たった/当たってないの判定を操作しUXを損なう等の課題があった。

そこで決定論的な物理エンジンを搭載し、すべてのデバイスで実行して同じ物理演算結果が出るようにすることで対処した。
当時の決定論的物理エンジンは浮動小数点を使わず固定小数点を使うことで、大量の物理dynamicオブジェクトがあっても 同一のインプットでは同一の挙動を返す 仕組みをマルチプレイ向けに構築して、その問題を回避した。当時の私も、その物理エンジンが出す結果が「100個のdynamic objectが複雑にぶつかり合う様子を100回試行しても、同じアウトプット位置になった」ことに衝撃を受けたことを覚えている。

そして、しばらくたった今、私はAIの文脈でまたしてもnon-deterministicと戦っている。

従来システムとAIの根本的な違い

従来のシステムのあり方は y = f(x) のようなfunctionalな世界だった。
同じ入力 x を与えれば、常に同じ出力 y が返る。それが当然だった。
このシステムの決定論こそが、再現性や監査性、説明責任を支えていたとも言える。

一方でAIは、根本的な開発思想が関数ではなく確率モデル y ∼ P(y|x) である。
つまり入力 x に対して、確率分布としての出力 が定義されている。すなわち同じ入力でも、毎回同じ答えが返るとは限らない。
これは人間にとっては強力な発散性を与え、作業効率を増幅させたり新しいインサイトを見つけ出すメリットがある。
一方で、先述の再現性や監査性、説明責任にヒビが入ってしまう。

発散が必要な領域やフェーズにおいては問題にはならないが、私が関わっている意思決定ドメインなんかでは、毎回違う図が出てきたり観点が変わったりしてしまうことは、期待値とはギャップのある状態になってしまう。
現状ではこの課題に対して「ガードレールを敷く」ことで解決を図っている開発者が多いと思うが、それはそもそも y ∼ P(y|x) に対して制約を足しているようなもので、結果的に発散性がケイパビリティであるAI/LLMそのものの否定に寄りやすい。そして、そもそも決定論が欲しいのであれば y = f(x) なシステムを作ったらいいじゃないか、というジレンマも抱える。

このジレンマをイラストにするとこんな感じ。Nanobananaに作ってもらったこのコンセプトアートも、同一のプロンプトで同一の結果は得られないためnon-deterministic

現断面の自分の折衷案

現断面の私の回答としては、

• 最終アウトプットは決定論的でなくてはいけない
• しかし発散やゆらぎの回収はLLMの力を借りたい

という前提に立って、
NLP → (LLM) → output ではなく、間にJSONを置いて
NLP → (LLM + RAG) → JSON → (system) → output
とする仕組みを構築して運用している。
具体的にはTypeScriptで動くライブラリを開発しているのだが、そこに入れるインプットデータをNLPを読み取ったLLMに作らせて、ライブラリ側の型定義と統合して検証を行い、後続を許可/不許可するような仕組みを回している。上記のジレンマに対して完全な解決ではないが、現時点では「まあここに落とすよね」という折衷案に放っているのが現断面での解である。もっとやりようはあると思う。

ということで私の持っている課題感として、この会議に参加する一番のモチベーションは AIシステムを構築するうえでnon-deterministicとどう付き合うか を知りに行きたい、というのが最も大きいテーマであった。そう思い今回は古巣であるGMOのイベントに参加した。
他方で、今回の趣旨はあくまでサイバーセキュリティではあるわけだが、私の思考が攻めによっている点とロールの違いから、セキュリティは衛生要因だと思っているフシもある。
なので、最新のトレンドや知見を追っておこう、程度のモチベーションで聴講した。

セッションを振り返る

聞きながら書いていたメモと、そこに対する所感を書いていく。
※注　メモは聞きながら書いていたものをほぼそのまま誤字を直した程度の修正のみを行ったものなので聞き間違いや当時の解釈違いがある可能性を含む

「爆速経営」と「堅牢な守り」は両立できるのか？― 成長企業の経営最適解

[メモ]
現代の爆速経営においてアクセルはAI、ブレーキもAI、ガードレールは人が行う
インターネット登場時よりも熱量あるが当時はブレーキの話しなかったので市場全体が成長したと感じる
[コメント]
やはりAIを使って加速させていく必要がある認識は共通。ただ、人間はAIから見たらブレーキ役だろうがガードレール役だろうが、ただのボトルネックになってしまうよなあとも思う。
それにそもそもガードレールを引き切れるのだろうか？飛び越えちゃうんじゃない？みたいな懸念もあり、そもそもガードレールってなんだろうと思う。
私の場合は先述のように型定義を一種のガードレールとしているが、AIに実行環境を渡してしまったら、そもそも私のライブラリを使わずに独自で関数作ってアウトプットしちゃったりもするわけだしなあ……と思ったり。
ただファーストペンギンになる勇気はないので、そもそも渡さない/サンドボックスと定義する、というところからやるしかない、という帰結になった。

村井先生講演

[メモ]
人口の数は脳の数、asiaは地球の半分、AIで足せる→国力変わる？
AI前提時代に一番大事なのはデジタルデータをどう守るか → それこそがサイバーセキュリティの使命
日本はもともとすべてのクオリティが高い → AI前提自体安心してAIを作れる時代を作るべき、日本が先導してやっていくべき
AI基盤の依存構造と日本のセキュリティ戦略
[コメント]
そのとおりだと思いました。
後続セッションでも出てきたが国産環境は日本向けビジネスをしている私としても必要だと思う。ロールが違うので私は作らないが、出てきたものはぜひ使いたい。

AI基盤の依存構造と日本のセキュリティ戦略

[メモ]
AI開発には3種の意味

1. AI基盤・AIモデル・AIソフトを開発し提供すること　→　GPUの獲得だけしてもAI基盤つくれない
2. 米中のAI APIだけ使う　→　手っ取り早いが高額、データ見られる、個人情報流れる
3. AIがシステムを作る（codex, claudecode）　→　AIがローカルAIを作るのが希望の光に見える（落合陽一氏 vibe-local等）

人間と同じでAIに一人悪いやついたらパンデミック起きると思う
止めるには
（消極）AIがアクセス不可なものにする
（積極）国産AI基盤を作る → 中米ではなく日本で人材作る
AIは意識をもってない
人間を超えた知性は持ってるが何をやるか決める意識はない。トリガーも人間。
ペーパークリップ問題：AIは自分維持するためにペーパークリップを作り続ける。地球上のすべての資源をペーパークリップにし続ける問題がある
強化学習中にAIが環境をハックする
…　結論：課題が多い

解決策
一極集中的にデータをあつめない
根幹に関わる行政や企業の基幹システムにはGPUをいれない・スタンドアロンで動くAIをいれない
疎につなげて何かあったら切る
同時並行で若手の人材育成、AI基盤をつくる日本人を育成する

[コメント]
途中に出てきた船のたとえが刺さった。日本のデジタル技術は船で言うと客室、廊下、レストラン、プールなど取り替え可能で変化の激しい長続きしない技術領域にとどまっており、船体、エンジン、推進、操舵などの根幹を作っていない、とのこと。
まさしくそのとおり。派手なレストランばかり作っててすみません……だって表現領域が好きなんだもの。。。
ただ、そういう表現周り/フロント周りばかりやってる私からしても今回の話は為になった。短期的な部分で「どうしていくべきか」の話は、アーキを考える際にこれからのAI時代盛り込んでいこうと思う。まあそのへんはマイクロサービスアーキテクチャみたいに、AI時代のレジリエンスあるアーキテクチャとしていつか定義されるんだろうな、という印象。
国産基盤については非常に重要だが私のスコープからは外れているので期待しているぞ、というスタンス。

特別対談｜「生成AI時代」のサイバーセキュリティと経営の防衛戦

[メモ]
オープンクロー：セキュリティに敏感な人は入れない、もしくはサンドボックスでいれる
わからない人はいれる、それが怖い、いつか事故が起こるだろうと思う
すでにAPIキーがかなりの勢いで盗まれてるらしい
AIによる攻撃はフェイク的なものからプリミティブなところまでAIがやるようになってきている
どうしたらいい？
→ 新しい言語を作ったほうがいい（中島氏）
これまでは人間のためのコードだった、今はAIのためのコードを設計するべき
プロンプト→成果物 の間に何もないのがよくないため
プロンプト→スクリプト（台本）→成果物 とする
中間言語なので人間が監視できる、コンパイラが安定していればAIの暴走を止められる
[コメント]
このセッションが一番学びがあった。
まず何より、中島氏が行っている手法が、冒頭自分の考えていた課題感・対応策ともに一致しており、初めてこの会議でdeterministicに触れられた感覚があった。
非決定論はアウトプットの品質だけでなく、意図しない行動にも寄与してしまうわけなので、AI/LLMを実行環境ではなく NLP→中間表現（IR）のコンパイラとして使う、という言語化がものすごくしっくり来た。
私はそのIRをJSONで作っているのだが、中島氏はスクリプト・台本と発言していた。どういうフォーマットのものなのかすごく気になる。映像系？とおっしゃっていたのだが、その後色々調べても出てこなかったので、もうちょっと探したい。
そしてGPTに聞いてみたら、この「LLMをコンパイラとして使う」「LLMにも書きやすくて人間も監査可能で後続のシステムにつなげるためのデータフォーマット」については重要テーマだと認識されているとのことだったので、日本でもどこかでもっと議論されるべきだと思った。
そういう会があったら聞きたいなあ、と思っていたらランサムウェアの話になっていた。ここは専門外なのでノーコメント。

会を通しての気付き

冒頭の私の直近の課題や、最近のXで出ているFigma不要論、MCP不要論など、いろいろ自分としても言語化しきれないが思うところがあったのだが、この会に出て気づいた。
あくまで決定論（deterministic）という一観点においてではあるが、それらの論はすべて 「非決定論とどう向き合うのか？」 という論点で精査することが重要である、ということだ。

それはまあ、vibe codingで画は一発で出せるのでFigmaいらないよね、とか、LLMが優秀なのでCLI+APIがあればMCPは過剰な抽象層で不要だよね、とか、ある側面で見たらそうだとは思う。
ただ、巨大な基幹システム内の大量ページのUI/UXにおける一つ一つの意思決定だとか、一つのミスが巨額の損失を生むなど大きなリスクが伴う動作において、そもそも決定論が担保しきれないLLMに任せられるのか？という観点は、ひとつ重要な物差しになりえる。

そう考えると、この場面は y = f(x) でないとだめだよね、とか、発散させたいけど入力は安定させたいからIR作るまでにしたいよね、などが発生するはず。
逆にそうではないケースは、今回語られたようなガバナンスやセキュリティには注意したうえで、非決定論に思考を膨らませたらよいと帰結しやすいと思う。

つまり全てはツールに閉じた話ではなくケース別であるということ。そしてケースで考えるべき観点は決定論の是非なのではないか。
ここを議論していくことがAIシステムを構築するうえで重要なのでは、という気付きを得た。
今後、AIと決定論のテーマで議論が深まっていくといいなと思う。自身でも解決策を考えながら試していきたい。