偶然のブラックボード

偶然のブラックボード Giles Edwards-Alexander GilesはThoughtworksの欧州、中東、インド担当CTOです。彼は25年以上のエンジニアリングとテクノロジーリーダーシップの経験を持ち、モバイルからAIまで、小売、フィンテック、ヘルスケアなどの業界で活躍しています。この記事は、「Exploring Gen AI」シリーズの一部です。このシリーズは、Thoughtworksの技術者がソフトウェア開発に生成AI技術を使用する探求を記録するものです。 2026年9月2日 今週、Thoughtworksヨーロッパでは、10名のエンジニアを集め、バルセロナのオフィスに一室に閉じ込めました。目標は、エージェントエンジニアリングに本気で取り組んだ場合に、どれだけ遠くまで、どれだけ速く進めるかを見ることでした。私たちはそれをハイパーエージェントと呼びました。その過程で、エージェントの調整に関する何かを偶然再発見しました。 10名のエンジニアは、航空会社のIROpsシステムを構築するという目標を与えられました。これは、航空会社がフライトコントロールセンターで、何かがうまくいかなくなったときに使用するシステムです。飛行機に修理が必要な技術的障害が発生した場合。乗務員が病気になり、乗務員を交代する必要がある場合。どのフライトをキャンセルするか、どの飛行機を交換するか、どの乗客を降ろしてホテルに収容するかなどを決定する方法です。これは、数百機の航空機、数十万人の乗客、そして多くの乗務員が複数の拠点や空港にまたがって関わる、非常に、非常に困難な問題です。IROpsシステムは、構築が複雑で、理解が複雑で、使用も複雑です。私たちは4日間でそれを構築することに成功しました。しかし、この記事はその方法についての話ではありません。 私たちは仕様とシミュレートされた航空機から始めました。これは実際のクライアントではなく、練習問題だったからです。何が機能し、何が機能しないかを見るために、いくつかのことを試しました。モノレポを使用しました。すべてのエンジニアが同時に作業を開始しました。私たちはただ始めましたが、数日後、興味深い方法で物事が起こり始め、物事が現れ始めました。 エージェントが多く一つのリポジトリで動作すると、ビルドパイプラインが苦しみました。これに対処するために、私たちは規律を導入しました。エージェントはメインから継続的にコミットし、リベースすることになりました。当初は、コミット後にリベースし、すべてのビルドチェックとコントロールを有効にしてからプッシュすることを要求しました。この変更は、ビルドの失敗をローカルでキャッチするために導入しました。早期かつ頻繁に統合するのです。しかし、副作用がありました。 私たちはエージェントに計画を立てさせ、作業を仕様のセクションにスコープさせ、それらのセクションにリンクされた計画を作成させました。これらの計画はリポジトリに保存されました。すべてのエージェントは、同じ仕様を使用し、同じ番号付けおよび識別されたセクションで作業していました。エージェントが作業するにつれて、計画は進捗を記録するように更新されました。これらの更新は、他のすべての更新とともに、新しいコミット規律で収集されました。エージェントはお互いの進捗を見ることができました。 例えば、あるエージェントがオペレーションを復旧するための特定の計画が有効かどうか、ハードコンストレイントやソフトコンストレイントを破るかどうかなどを判断するコンポーネントである評価者を担当していました。同時に、別のエージェントが、混乱を解決できる計画を探す検索アルゴリズムに取り組んでいました。検索コンポーネントは評価者に依存します。各コンポーネントは一緒に書くことができますが、共有インターフェースがあり、検索は評価者に依存します。 計画はこれらの統合ポイントを記録しました。ある計画は、この時点で実際の検証者を呼び出すための呼び出し元を更新する必要がある、と述べていました。検索側では、この時点で実際の検証者が到着したときに呼び出すための呼び出しを挿入する必要がある、と述べていました。両方のエージェントが各計画と進捗を見ることができました。 私たちはエージェントが計画を使って調整していることに気づきました。あるエージェントが計画の1行を「進行中」とマークすると、別のアージェントがそれを見て、その行に取り組むことはありませんでした。最初のエージェントが終了すると、別のアージェントは作業が完了したこと、したがって続行できることだけでなく、その行がどのように実装されたかについてのメモを直接受け取ることになります。 私たちはこれを利用し始めました。セッションを開始し、特定のジャーニーに取り組むように指示しました。一例として、検証者とともにコストモデルを導入しました。誰かがコストモデルに取り組んで継続的にコミットをプッシュしていることを知っていたので、検証者に取り組んでいるエージェントに、計画とソースを見て、リポジトリを監視し、コストモデルの作業が完了したらそれを統合するように指示しました。そしてそれは実行されました。 これは完全に場当たり的でした。それは一連の決定の偶然でした。私たちはそれが起こるのを見ました。そしてそれから使い始めました。 エージェントのための偶然のブラックボードとしてのリポジトリ 私たちのエージェントが発見したパターンには名前があります。それはブラックボードシステムです。これは私が大学時代に探求したものでした。私の研究論文は、階層センサーによるエージェント行動の指示に関するものでした。当時の最新の機械学習技術、例えば強化学習を、大規模で動的なデータセットに適用することを検討していました。文献を振り返ると、コアの調整構造としてブラックボードパターンを採用しました。これは、1980年のHearsay-IIシステムの開発で以前に発見されていました。その後、1986年にGelernterらによってより形式的なタプルスペースの概念に発展しました。 ブラックボードまたはタプルスペースは、自律エージェントが独立して読み書きできる共有メモリです。それらは、ある最小構造を持つタプルを読み書きし、その後、好きなだけ追加フィールドを追加します。スキーマはありません。これは、自律的な問題解決者が単一の目標に向かって協調するための非常に効果的な技術です。それらは問題の分解された部分をそれぞれ解決し、その解決策を共有スペースにドロップし、ラベルを付け、他の自律的な検索者がそれを見つけて、それを自分の作業の一部として使用することができます。 私たちは偶然、エージェントにリポジトリをブラックボードとして使用するように促しました。しかし、それは偶然でした。意図的な行為ではありませんでした。完全に構造化されていませんでした。ブラックボードが機能する主要な部分がいくつか欠けていました。そして偶然だったため、エージェントにそれを再び確実に実行させるように促すことができるかどうかは確信が持てません。私たちは分析を行い、この連鎖反応を引き起こした単一のプロンプトを特定したので、何をしたかはかなりよくわかっています。しかし、それは創発的な行動でした。指示された行動ではありませんでした。 意図的に作成することに加えて、この通信チャネルをソース管理から独立させたいと考えています。頻繁なプッシュサイクルを指示することで作成しましたが、それから後退しました。頻繁なコミットはCIパイプラインを過負荷にしていました。よりまとまった変更が完了したときにのみプッシュするように切り替えました。これにより、エージェントは進捗の継続的な更新フローを得られなくなりました。 良い偶然の解決策には、良い意図的なプロジェクトが必要です。私はTalwrnというプロジェクトを開始しました。これはウェールズ語で、議論や対立が解決される場所、つまり「脱穀場」を意味します。これはエージェントエンジニアリングのためのブラックボードになることを目指しています。私の目標は、プロジェクトにすぐに組み込め、エージェントが作業を調整するための通信チャネルを即座に提供する、非常に使いやすいツールです。最初のステップは、Talwrnが自身の開発をサポートできるレベルに到達することです。純粋なエージェントエンジニアリングがどのように進むかの単一の進化する例として、それを使用するつもりなので、定期的に投稿する予定です。 最新の記事 (9月2日): 偶然のブラックボード 前の記事: エージェントループ内のTDD - 劇場か実際の価値か？