스크립트
00:00:00それでは、皆さん見えていますね。
00:00:15皆さん、こんにちは。
00:00:17ご参加ありがとうございます。
00:00:18今回は、もし企業固有の脳（カンパニーブレイン）を
00:00:23構築した場合の話をしたいと思います。
00:00:25それはおそらく会社の機密情報を漏洩することになります。
00:00:28それこそ私たちが企業脳の構築に対して抱いている最大の懸念であり、
00:00:32例えば、インターンが会社に入社してきて
00:00:34突然給与の詳細を知ってしまうような
00:00:36状況のことです。
00:00:37そうした事態は防ぎたいものです。
00:00:40これはおそらく、私たちがOpenClawやHermesを
00:00:43あちこちに導入するのを躊躇させてきた最大の要因であり、
00:00:47同時に別の理由でもあります。
00:00:49つまり、――
00:00:50数日前のClaudeTagの最近のローンチが持っていたような
00:00:52大きなチャンスでもあったわけですが、
00:00:54そこでは企業脳になる予定でした。
00:00:56ところが、誰もがこう思ったのです。
00:00:57いや、どうも企業脳にはなりそうにないぞ、と。
00:01:00違いますか？
00:01:01そこで今回は、何がそれを困難にしているのかについてお話しします。
00:01:03本題に入る前に、この企業脳というビジネスについて少し理解し、
00:01:07分析してみましょう。
00:01:09私はタンマイです。
00:01:10PromptQLのCEO兼共同創業者です。
00:01:13PromptQLについては後で確認していただくとして、私たちチームの背景として
00:01:18これを構築してきた経験は――Hustle Graphから来ています。
00:01:21私たちはHustle GraphQLエンジンの開発者です。
00:01:23GraphQLの分野で非常に人気の高いオープンソースプロジェクトであり、
00:01:26多くのデータアクセス問題を解決してきました。
00:01:28AppleからMeta、JPMorganなどに至るまで、あらゆる場所に導入されています。
00:01:32そのおかげで、
00:01:33データやデータセキュリティに対して多くの基盤や――ある種の愛憎関係が生まれました。
00:01:39そこで今回は、私たちが昨年から取り組んできたことや、
00:01:43そこから得た学びをご紹介します。
00:01:44皆さん自身がそれを持ち帰り、実践し、試すことができるようにするためのものです。
00:01:51もちろん、講演の最後には意見を交換し合ったり、
00:01:53何が機能して何が機能しないのかを確認したりできればと思います。
00:01:56もちろん結構です。
00:01:58昨年1年間、私たちは規模の面で何らかの急成長を見せた
00:02:01少数のパートナー企業とだけ提携してきました。
00:02:06これまでに約15〜20社ほどです。
00:02:08そして今、他の人たちにも門戸を開き始めているところです。
00:02:12その過程で、私たちは全く異なるニーズを持つ
00:02:153つの異なるタイプの顧客層を見てきました。
00:02:171つ目は、動さえすれば何でもやるというAIネイティブ企業です。
00:02:202つ目は、Instacartのような、
00:02:22最高峰のテクノロジーを好む技術志向の企業です。
00:02:25彼らは迅速に行動します。
00:02:27多少の不具合には寛容ですが、
00:02:30とにかく本当に優れたものでなければなりません。
00:02:33そうですよね？
00:02:34そして3つ目が、桁外れのセキュリティレベルを持つ
00:02:36フォーチュン100に名を連ねる銀行です。
00:02:38そうなってくれて本当に神に感謝しています。私のお金が入っている銀行ですからね。
00:02:41銀行の中でVibeコーディングされたAIエージェントが
00:02:43勝手に動き回るのは絶対に嫌ですから。
00:02:45そのため、彼らには多くのセキュリティルールがあります。
00:02:48本当にありがとうございます。
00:02:51しかし、そうした場所においても、企業ブランドの始まりや
00:02:54前頭葉のような部分として、
00:02:55私たちは導入されています。
00:02:59ですから、そうした学びについてお話しすることができます。
00:03:01私たち自身が企業脳を構築してきた経験では、
00:03:02ページ数にして約5,000ページほどになります。
00:03:05したがって、私たちはそれをWikiとしてモデル化しています。
00:03:10どのようにモデル化しても構いません。
00:03:13GitHub上のMarkdownファイルのセットとしてモデル化してもいいですし、
00:03:14グラフフラグ……覚えていますか？
00:03:16ナレッジグラフでモデル化することもできます。
00:03:17やりたいようにやればいいのです。
00:03:21好きな場所に配置することができます。
00:03:23ただ、私たちの場合は約5,000の相互接続されたページで構成されています。
00:03:25皆さんへの質問です。
00:03:27仮に、うまく機能する企業脳があったとしましょう。
00:03:32順調に稼働していて、準備もすべて整っているとします。
00:03:33その企業脳に対しては、毎日ある程度の数のアップデートが
00:03:36発生するはずですよね？
00:03:37財務、人事、エンジニアなど、社内のあらゆる人から
00:03:40情報を学習していくわけですから。
00:03:41では、企業脳で起こる1日あたりのアップデート数をグラフにプロットすると、
00:03:44どのような形になるでしょうか？
00:03:47おおむね右肩下がりのトレンドになるでしょうか？
00:03:47これらはすべて適当なグラフですが――
00:03:52最初はあって、それから下がっていくような形でしょうか？
00:03:55あるいは、アップデートが急増するにつれて上下しながらも横ばいになるでしょうか？
00:04:00それとも、着実に右肩上がりに増加していくでしょうか？
00:04:04共有スキルリポジトリへのコミット履歴が
00:04:05どのようなものになるか考えてみてください。
00:04:09健全な企業脳に対しては、毎日どれくらいのアップデートが
00:04:12行われているのでしょうか？
00:04:16そのトレンドはどのようなものだと思いますか？
00:04:18オプションAだと思う人はいますか？
00:04:21オプションAだと思われる方？
00:04:26なるほど、分かりました。
00:04:27オプションBは？
00:04:29オプションCは？
00:04:31面白いですね。
00:04:33それで、健全な企業脳がどのようなものか確かめるために
00:04:34私たちのデータをプロットしてみたところ、
00:04:371つ目について言えば、要するにこういうことです。
00:04:39最初は非常に熱意があった。
00:04:411日目や2日目に企業脳を構築した。
00:04:44誰かにタスクを与えて、「共有スキルリポジトリをすべて作り、
00:04:47Slackをすべてスクレイピングし、メールもすべてスクレイピングして構築してくれ。
00:04:50みんなで使うから」と言った。
00:04:53そして誰も気にしなくなる、というパターンです。
00:04:56あるいは、自動学習するシステムがある場合です。
00:04:57社内にHermesをデプロイしているような場合ですね。
00:04:59コメントがどんどん追加されていく様子を見てみると、
00:05:02熱意を持つ人が誰であるかに応じて、
00:05:03上下動を繰り返しながら推移していきます。
00:05:05そして、直近2ヶ月間の履歴をプロットしてみたところ――
00:05:07もっとも、これは少し古いデータですが――
00:05:09このような結果になりました。
00:05:11私は正直ショックを受けました。
00:05:12「なぜ増え続けいているんだ？」と思ったのです。
00:05:14なだらかな曲線ではありますが、
00:05:15なぜ緩やかに上向きに伸び続けているのでしょうか？
00:05:191日あたりのアップデート数が増加しているのはなぜなのか？
00:05:22それを見るのは非常に興味深いことでした。
00:05:24というのも、私が気付いたのは、システムが機能し始めると、
00:05:26人間はそれにさらに多くのことを教え込むようになるということです。
00:05:30それは例えるなら、
00:05:32でもなぜ緩やかに増え続けているのか？
00:05:341日あたりのアップデート数が増加しているのはなぜか？
00:05:38それを見るのは非常に興味深いことでした。
00:05:39私が気づいたのは、機能し始めるシステムがあると
00:05:42何が起きるかというと、人々はそのシステムに多くのことを教え始めるということです。
00:05:46例えば、データクエリのスキルを教えたとしたら、明日には
00:05:50そのデータを解釈するスキルを教えるということです。
00:05:53そしてその翌日には
00:05:55それに基づいてアクションを起こす方法を教えます。
00:05:57その次は、どうやって
00:05:59A/Bテストを行うかを考案する――このように人々は
00:06:00次々と新しい要素を追加していくわけです。
00:06:03しかし、すべてがエージェントであり、どれほど学習させても
00:06:05完璧ということはなく、それぞれに一定の安定したペースが存在します。
00:06:08そうですよね？
00:06:08ですから、そのペースは――
00:06:10安定したペースの分も積み重なっていくのです。
00:06:12そして、私たちが構築したシステムでも同じ傾向に気づき始めました。
00:06:15これは初期段階なので、最終的に勢いが衰えるかどうかは誰にもわかりません。
00:06:18もしかしたらBプランに似てくるかもしれないですね。
00:06:20しかしもちろん、健康な脳であれば、全体のサイズは増え続けます。
00:06:24ですが、1日あたりのアップデート数自体も増え続けていくのです。
00:06:28つまり、それはあなたが優れた脳を構築できたという証拠です。
00:06:32自社のために構築した、健康な脳の証拠なのです。
00:06:35素晴らしい。
00:06:36では、カンパニーブレインのユースケースとして、私たちがどのように
00:06:39機密情報を漏洩させないシステムを構築するかを分析していきましょう。
00:06:42ユースケースは2つあります。
00:06:44最初のユースケースは、カンパニーブレインが存在するというものです。
00:06:48それをAIやエージェントなどで活用して仕事を完了させたい、ということですね。
00:06:55その例をお見せしましょう。
00:06:56顧客から回答を求められるセキュリティ質問票が
00:06:59メールで送られてきたとします。
00:07:00そこでAIに、「カンパニーブレインを検索して
00:07:03このセキュリティ質問票に答えるのを手伝ってくれ」と頼むわけです。
00:07:05これはカンパニーブレインの非常に正当なユースケースです。
00:07:082つ目は、非常に有用なユースケースです。
00:07:10なぜなら、他の人々の知識が自分のもとに集まってくるからです。
00:07:14カンパニーブレインの2つ目のユースケースは、CloudTagに少し似ていますが、
00:07:18マルチプレイヤーという概念です。
00:07:21もしSlackなどの場所にエージェントを配置し、複数の人が
00:07:25対話できるようにしてきたなら、それは共有AIとして使っているようなものです。
00:07:29つまり、物事を成し遂げるということです。
00:07:32その一例として、協調的なインシデント管理などが挙げられます。
00:07:36例えば、「おい、ログを取ってきてくれ」と言いたいとします。
00:07:40インシデントが発生したので調査したい。
00:07:42ログを取ってきて、コードベースを調査し、PRを作成し、ステージングにデプロイし、
00:07:46本番にデプロイし、アラートを設定する、といった具合です。
00:07:48複数の人がカンパニーブレインを使って作業を行いたいわけです。
00:07:51これらがカンパニーブレインの2つのユースケースです。
00:07:531つは共有された協調的知識のユースケースであり、
00:07:56もう1つは共有AI自体のユースケースです。
00:08:00その両方に、大きなセキュリティ上の問題が存在します。
00:08:06では、そのセキュリティを確保するために、その概念をもう少ししっかりと定義してみましょう。
00:08:15では、カンパニーブレインとは一体何でしょうか？
00:08:18これが私の定義する意味での…
00:08:20それはMarkdownに格納された共有コンテキストであり、
00:08:23一連のMarkdownファイルに配置されるものです。
00:08:26そしてそれは、コーディングエージェントに与えたいと望む
00:08:29様々なデータやツールに対するアクセス制御ルールです。
00:08:34私がそれをこう呼んでいるのは――
00:08:38私が話しているのだから、好きなように定義できるからです。
00:08:41それが私の定義です。
00:08:42つまり、LLMに取り込まれて
00:08:46ツール呼び出しを行うような知識だとは言っていません。
00:08:48汎用的な処理を行うAIではありません。
00:08:51それは、投げかけられたどんな問題も解決するコーディングエージェントとしてのAIなのです。
00:08:56皆さん既にお聞きかもしれない前のセッションと少し似ていますが、
00:09:00つまり「コーディングエージェントを使って一般的な問題を解決できないか？」という発想です。
00:09:04まさにそれです。
00:09:05最も単純な例として、「ツイートを書いて」と頼む場合、それはAI呼び出しを行って短いツイートを作成する小さなスクリプトを書いていることになります。
00:09:13おそらくそんな必要はありません。
00:09:14AI自体がツイートをそのまま返せばいいのですから。
00:09:17しかし本質的に、Claude Codeがあらゆる用途に使われているように、
00:09:20Claude Co-workも同じアーキテクチャです。
00:09:22Codexアプリも同じアーキテクチャであり、コーディングエージェントを使って汎用的な問題を解決できるという気づきに基づいています。
00:09:28私たちはそのための脳を構築しているのです。
00:09:30企業向けの巨大なナレッジグラフやナレッジベースを作ってからそれを保護しようとしているわけではありません。
00:09:34そもそもそんな方法はうまく機能していませんし、今後もうまくいきません。
00:09:39では、企業の脳の設計にどうアプローチすべきか、「企業の脳を構築すべきか？」という問題について考えてみましょう。
00:09:50もしあなたが大企業の社員で、仕事もせずに時間を潰すのが好きなら、企業の脳を作るというアイデアを気に入るでしょう。
00:09:57なぜなら、「よし、2年間のプロジェクトを引き受けてJPモルガンの企業の脳を構築しよう」と思えるからです。
00:10:02そんなことは実現しません。
00:10:03100年の歴史を持つ組織の企業の脳など作れるはずがありません。
00:10:07せいぜい発足して数ヶ月か数年の自分の家庭向けでさえ、まともに作るのがやっとです。
00:10:13したがって、企業の脳を構築するアプローチとして私たちが目指すべきなのは、社内で少しずつ仕事を行っている一人ひとりが、自分の担当部分の企業の脳を所有し構築することです。
00:10:23それこそが構築すべき方法なのです。
00:10:25これが私が掲げる制約の2つ目です。
00:10:271つ目はカンパニーブレインの定義、そして2つ目は構築に向けたアプローチの仕方です。
00:10:33私は次のような言い方が好きです。つまり、企業の脳は「作る」のではなく「育てる」のだということです。
00:10:41自然にまとまるようにするのです。
00:10:43自然に形作られるようにする。
00:10:44システムは自然に統合される必要があり、そうでなければ構築は不可能です。
00:10:47わかりましたか。
00:10:48大まかに言えば、一人ひとりが自分の企業の脳の部分をセルフサービス形式で担えるようにしたいのであり、これらが従うべきさまざまなステップとなります。
00:10:57時間が許せば後で詳しく戻って説明しますが、まずは具体的なユースケースから始めましょう。
00:11:03この具体的なユースケースにおいて、私がお見せしたい現実的な例は次のような状況です。
00:11:12セキュリティアンケートの例を挙げます。
00:11:15Stitch FixのDaveからメールを受け取り、そこに答えたい一連の質問があるという状況です。
00:11:20メールを開くとセキュリティオンボーディングのスクリーンショットが含まれており、それらの質問に対する回答が自動で作成され始めます。
00:11:30どうやってそれを知ったのか皆目見当もつきません。
00:11:32トラストセンターのことやセキュリティ体制、ゲートウェイの有無など、すべての質問に答えているのを見て非常に驚きました。
00:11:40何らかの処理を行ってくれます。
00:11:41これらすべてが企業の脳から引き出されており、私は「そのままこれを送ってくれ」と指示するだけです。
00:11:50「この下書きが気に入ったから、Daveにそのまま送信して」と指示します。
00:11:53するとメールが送信されます。これがやりたいことの非常にシンプルな例です。
00:11:57ここで課題となり問題となるのは、ある人が貢献した内容を、第3者が利用できるようなシステムをどのように構築するかという点です。
00:12:13セキュリティ体制に関するこの知識はどのようにして取り込まれたのでしょうか？
00:12:18おそらく、他の誰かが同じセキュリティアンケートに取り組んでいたのでしょう。
00:12:22つまり、Hermesエージェントなどを使っていたわけです。
00:12:24彼らはそれに取り組んでいました。
00:12:25何らかのメモリが自動保存されます。
00:12:27誰かがスキルを書き留めたのかもしれません。
00:12:28何らかの形でその断片が私のAIエージェントに届く必要があります。
00:12:32それをどのように可能にするのでしょうか？
00:12:35それでは、誰もがGitHub上で互いに共有スキルを書き込むという、1つ目の分かりやすい方法を試してみましょう。
00:12:42セキュリティ担当者が初めてセキュリティアンケートに回答したとします（皆さんの頭の中にもセキュリティおよびコンプライアンス担当者の姿が浮かんでいるでしょう）。
00:12:50考えてみてください。アンケートに答えた後、そもそもアンケートに答えるのは面倒な作業です。
00:12:56この巨大なExcelシートのようなアンケートに回答した後、彼らがわざわざGitHubに行って共有スキルを更新したとしましょう。
00:13:04皆さんの周りには、キリスト教の聖人のような、GitHubのリポジトリで共有スキルを親切に更新してくれるほど素晴らしい人たちがいるかもしれません。
00:13:16しかし、ほとんどの人はそんなことをしません。
00:13:18GitHubで他人のためにスキルを書いてくれる人などいません。
00:13:24つまり、それは私たちの自然な行動ではないのです。
00:13:27日々の業務の中で、「これは将来、面識すらない、関係のない誰かにとって非常に役立つかもしれない」などと突然思い立って行動することはありません。
00:13:39絶対にありえません。
00:13:40自分の記憶やコンテキストを整理するだけでもやっとです。
00:13:44他の人のためにそれを書き留めて送るような時間は到底ありません。
00:13:492つ目に、会社全体の脳を作る代わりに、チームの脳を作ってはどうか？
00:13:53全員で一つの共有スペースを使えばいいのでは？
00:13:55セキュリティチームが、こういう作業ができる共有のサイロをもう一つ使えばいいのではないでしょうか？
00:14:01つまり、エージェントを構築し、それ自身にメモリへ保存させるわけです。
00:14:04皆さんの多くも、SlackにHermesのようなものを追加して、似たような構成にしているかと思います。
00:14:09複数の人がAIを使い、自動でメモリに保存してコンテキストを追加するような、チーム全体の脳の仕組みを導入している方はいますか？
00:14:18小さなチームですでにそのようなスキルを使っている方はいらっしゃいますか？
00:14:231人。他には？なるほど。
00:14:24何人かはいらっしゃるんですね。素晴らしい。
00:14:26これは良いのですが、問題は依然として孤立しているため、会社の脳とは言えない点です。
00:14:31つまり、さらなるサイロが増えるようなものです。例えば、claw tagなどでは、チャンネルごとのメモリが作成されます。
00:14:40すべてのチャンネルで保存はされますが、結局はそのチャンネル内の別のサイロになってしまうわけです。
00:14:46そのため、他の場所では使えない特定の場所に再び閉じ込められてしまいます。
00:14:50誰かがそのチャンネルに追加されれば機能しますが、そうでなければ機能しません。
00:14:55そこで3つ目の選択肢があります。
00:14:593つ目の選択肢は、すべてのコンテキストを1つの共有Wikiに集約することです。
00:15:06WikiとはMarkdownファイルの集まりであり、Markdownファイル同士はリンクさせることができます。
00:15:08つまり、巨大なフォルダを想像してください。
00:15:10そのフォルダにはたくさんのMarkdownファイルが入っています。
00:15:13そしてMarkdownファイル同士をリンクさせることができます。
00:15:16そのため、すべてのコンテキストをフォルダ内に保存したりサイロ化したりする代わりに、
00:15:21Markdownファイル、あるいはそれに相当するファイルに配置し、
00:15:25互いにリンクできるようにするのです。
00:15:282つ目に、各ファイルに対してスコープを設定できるようにします。
00:15:33それは、そのファイルに対して誰が読み取りや書き込みのアクセス権を持つかという制御です。
00:15:38そして3つ目、これが最も重要なことですが、
00:15:42エージェントにメモリを自動追加させないということです。
00:15:49自動追加を許可してはいけません。なぜなら、自動追加されると何が起きたのか全く把握できなくなるからです。
00:15:55それでは元に戻ってしまいます。勝手に色々なデータが追加されていき、
00:16:00そのエージェントのメモリに含まれている間だけは運が良い、というような世界に逆戻りです。
00:16:04そのため3つ目として、エージェントに自動追加させるのではなく、
00:16:07どのようなスコープで何を追加すべきかをエージェントに提案させ、
00:16:16人間がそれを承認または拒否できるようにするのです。
00:16:21GitHubのように、わざわざ自分でコードを書き、共有スキルを更新し、
00:16:28PRレビューを行ってマージしてもらうほど大がかりではありません。
00:16:30かといって、エージェントによってメモリが無計画に自動書き込みされるような無責任な状態でもありません。
00:16:36ちょうどいい落としどころです。作業を行いながらポップアップを表示させ、
00:16:40適切なスコープを提案させて誰かに追加してもらうのです。
00:16:45この非常にシンプルな仕組みを追加することで、ユーザーは巨大なWikiに情報を追加できるようになりつつ、
00:16:51自分が見られる範囲についてその本人が責任を持つことができます。
00:16:57例えば財務関連のWikiに追加する場合、機密情報を扱っているので、
00:17:01確実に財務用のスコープを持たせたいと考えます。
00:17:03個人的な内容を追加する場合は、確実に個人用スコープにしたいと考えます。
00:17:06実際のUIの例をお見せしましょう。私たちがやっているのはこういう形です。
00:17:15これは、弊社の営業担当の1人から、通話への参加を依頼されて受け取った最近のメールです。
00:17:33私はそのメールを確認して返信を助け、その後、追加される内容を箇条書きで
00:17:39提案してくれる小さなボックスが表示されました。
00:17:43「Wikiに追加」を押すと、追加される内容の確認がはるかに簡単になります。
00:17:47こちらのMarkdownファイルに追加されるか、あちらのMarkdownファイルに追加されるかなどは気にしません。
00:17:52リンクの処理はエージェントがやってくれます。私が気にするのは「この事実は正しいか？」という点だけです。
00:17:58事実が正しければ、「Wikiに追加」を押すだけで完了です。
00:18:02Wikiに追加する際、Wikiのページごとにどのようなスコープを追加すべきかを選択できます。
00:18:08つまり、Wikiの各ページ自体に、誰が何にアクセスできるかを決定するための特定のスコープを設定できます。
00:18:12例えば私のメールの場合、これはメールおよびメールの優先順位付けに関するWikiページであり、
00:18:17誰がこれにアクセスできるか、誰がオーナーで、これに対するRBAC（ロールベースアクセス制御）がどうなっているかを自分で決められます。
00:18:22どのようなシステムにするかは皆さん次第ですが、核心となるアイデアは、
00:18:26エージェントに直接変更を行わせるのではなく、変更を「提案」させるということです。
00:18:32ルールは2つあります。1つ目は、すべてを社内共通の1つのWikiに入れること。このルールは絶対に曲げないでください。
00:18:382つ目は、その一環として、すべての変更に人間の名前が紐づいているようにすることです。
00:18:44「Claudeが追加した」や「AIエージェントが追加した」、「Hermesが追加した」といったものはWiki内への追加を一切許可してはいけません。
00:18:51「タンメイが追加した」のように、誰が追加したのかの名前が必要です。
00:18:57そうすることで、全員の報酬情報などをうっかり全員に見える状態にしてしまった失敗の責任者が誰であるかを特定できます。
00:19:04その上で、何らかの是正措置を取ることができます。
00:19:09例えばPIP（業績改善計画）対象にするなどです。「Wikiの編集方法も知らなかったのか」となるわけですから、これは非常に重要です。
00:19:14そしてルール2として、それが決まったら、次にスコープの段階に進むことができます。
00:19:19つまり、ユーザーが簡単に行えるようにする必要があり、そこでスコープの出番となります。
00:19:23アクセス権限に応じて各ファイルをスコープ分けし、その周りにシステムを構築していくのです。
00:19:26そのアーキテクチャの図はこのようになります。ユーザーがいて、
00:19:32ユーザーはエージェントと対話します。エージェントはコンテキストを読み取る際、その特定のユーザーのクレデンシャルを使用します。
00:19:39つまり、財務関連の問題を解決するために何かを読み込んでいる場合、財務のクレデンシャルを使用して
00:19:46私として読み込みます。私には財務のWikiへのアクセス権があるため読み取ることができ、これが毎回行われるのです。
00:19:52つまり、エージェントは常にユーザーのクレデンシャルを使用してWikiの正しい部分を読み取ります。
00:20:00さて、2つ目のユースケースにはもうあまり時間がありません。そのため、2つ目のユースケースの
00:20:06雰囲気だけを簡単にお伝えしつつ、このアイデアを拡張します。これが本丸のユースケースです。
00:20:13これは非常に複雑なユースケースです。なぜなら今や、
00:20:171人だけでなく、私たちの一団が共有コンテキストを使用して問題を解決するためだからです。
00:20:25その際、さまざまな異なるエスカレーションや権限レベルが同時に絡み合ってきます。
00:20:31そして、これらこそがAIとのインタラクションの中で、会社の集合知が最も多く生み出される場面なのです。
00:20:36例えば、私たちの実際の事例を簡単にお見せしましょう。これはSREの状況におけるケースですが、
00:20:50誰かが、「おい、自動学習、Wiki学習（かなりメタですが）が失敗しているぞ、動かないんだが
00:20:57どうなっているんだ？」と言い出したのです。そして調査が始まりますが、スキルがなかったために失敗します。
00:21:02そこで「おい、こうするな。このOpenTelemetryのスパン名を使ってくれ」となります。OpenTelemetryのスパン名を使うと、
00:21:07少しマシにはなりましたが、それでもまだ非常に遅かったのです。そこで彼はコードを見て、
00:21:13「おい、likeクエリを使っているじゃないか。お前はバカか」と言いました。
00:21:18これはOpus 4.5です。「こんなことするなよ」というわけです。そして、「likeクエリを使うな、
00:21:24equalsクエリを使え」と言います。equalsクエリを実行するといくつかの詳細が浮き彫りになり、
00:21:29さらに「ここをもっと深く掘り下げろ」と指示します。すると、エラーの原因となっている
00:21:33コードの行が特定されます。単純な話ですね。ここでいくつかの知識が表面化し、
00:21:39「なるほど、likeではなくequalsを使うべきだと学んだぞ」となります。「Wikiページ名にカスタムプレフィックスを
00:21:45追加すると問題を引き起こす可能性があると分かった」というわけです。このように、受け入れるかどうかを選べる
00:21:50学びを提示してくれます。彼は問題の本質についてさらに深く掘り下げていきました。
00:21:56そこに別のメンバーが会話に参加してきて、こう言いました。「ここで私たちが下した技術的決定は間違っている。
00:22:02なぜこんなことになっているんだ？」と。そして2人が議論を始めます。口論になるわけです。
00:22:09「おい、こうあるべきじゃないだろ、こうあるべきだ。でもなんでこうなってんだ？ いや、こうあるべきだ」と。
00:22:12この議論から知識が生まれます。なぜなら、本当の問題は誰かが
00:22:17文書化されていない技術的決定を下していたことだったからです。その問題を修正しようと決定し、
00:22:22それが確かに根本原因であることを確認して、こう修正すると決断します。
00:22:26「おい、問題を引き起こしているこのプレフィックスを削除しよう」といった具合に。
00:22:31そうすることで、脳に追加される最高品質のコンテキストが生まれます。というのも、以前の提案は
00:22:38「ページにはプレフィックスがあってはならない」ではなく、「ページにプレフィックスがあること自体が問題だ」というものだったからです。
00:22:44ですから、脳に文書化すべきことは「ページにプレフィックスを持たせるべきではない。
00:22:49プレフィックスがあると、本番環境でルックアップの問題を引き起こす可能性がある」となります。これは複数の人が互いに話し合い、
00:22:54協力して問題を解決するときに起こります。Slackのスレッドで2人が議論して
00:22:59問題を解決するときに起きるのがまさにこれであり、最高品質のコンテキストが生まれます。だからこそ
00:23:05これが求められるわけです。しかし課題は、これにまつわる権限昇格が非常に、
00:23:10非常にシリアスになるという点です。複数の人間が関わりながら何でもできるエージェントを構築している場合、
00:23:18それは恐ろしいことです。あるエンジニアがPR（プルリクエスト）の作業を行うことは許可されていても、同じエージェントを使って
00:23:23本番環境にデプロイできるとなれば、それはあまりに危険です。デバッグと
00:23:29安全なデプロイを同じ会話の中で行うことはできません。特に銀行にいる場合はなおさらです。例えば、デバッグを行う人、
00:23:35ステージングにデプロイする人、アラートを設定する人、そして本番にデプロイする人は同じではありません。しかし、それらが同一人物であることには
00:23:40大きな価値があります。なぜなら、そこにこそすべての知識が集まっているからです。そうした背景から、
00:23:452つ目のアーキテクチャに行き着くわけです。これについてはあまり詳細には踏み込みませんが、
00:23:49ユーザーのクレデンシャルやクレームを使用してコンテキストを読み取るという先ほどのアイデアと同じだと考えてください。それと同様に、コードがツールを実行する際にも
00:23:58ユーザーのクレデンシャルを使用します。つまり、サンドボックス内にクレデンシャルを保存してはなりません。
00:24:05その代わりに、HTTP層やSQL層でユーザーのクレデンシャルを注入し、特定のインタラクションにおいてAIが人間として振る舞えるようにするのです。
00:24:13このように、興味深い詳細がいくつかあります。しかし、これこそが共有AIに共有コンテキストで動作を可能にさせるものです。
00:24:20そしてそれらが、作業を進める上での2つの重要な要素となります。要約すると、このアーキテクチャは特別複雑なわけではなく、
00:24:30この2つのルールから逆算すれば非常にシンプルに構築できます。「クラウドのサンドボックスにクレデンシャルを保存しないこと」、そして2つ目が
00:24:36「実データとのすべてのインタラクションを仮想化し、プロキシ経由にし、仮想化する（どのような表現でも構いません）」ということです。
00:24:41そしてユーザーにそれらを制御させます。つまり、特定のツールを追加したユーザーが、その特定のツールに誰がアクセスできるかを制御すべきなのです。
00:24:48これら4つの原則に従い、そこから逆算して考えれば、この全体の仕組みを導き出すことができます。
00:24:53コンテキストの管理方法、設定する制約、ツールの管理方法、そして設定するセキュリティルールにおいて、
00:24:58筋が通るアーキテクチャは、実質的にこれしか存在し得ません。
00:25:02そろそろ時間となりました。講演の後でもお気軽に話しかけてください。ブースも出展していますので、
00:25:10このアーキテクチャの内部にあるニュアンスについて、ぜひさらに語り合いましょう。私はTwitterのTanmay Gohです。
00:25:16私たちはPromptQLという会社をやっています。ぜひチェックしてみてください。AIエンジニアリングコミュニティに向けて、
00:25:24まもなくプロダクトのローンチを行います。ですから、皆さんにもぜひそれをシェアしたいと思っています。
00:25:30後でシェアできるように、ステージ上で皆さんと一緒に写真を撮りたいと思います。ですので、ここにいる間にさせてください。
00:25:40それでは、皆さん「チーズ」と言っていただけますか？
00:25:45本当にありがとうございました。私たちのCloud Tagに対するアプローチであるPromptQL Tagにぜひご注目ください。
00:25:52これは、私たちがここで議論したアイデアによく似ていますが、Cloudに縛られることはありません。
00:25:57GLMも使えますし、GPTも使えます。さらにSolも登場するので、それらを使って大いに楽しむことができます。
00:26:03ぜひチェックしてみてください。それでは、また近いうちにお会いしましょう。
00:26:19まもなく再開します。