記事 on 2389 Research, Inc

ホートンはささやきを聞く

Wed, 20 May 2026 09:00:00 -0500

オフィスで何が話されているかを継続的にまとめたいと思っていました。監視ではありません。部屋が自分のために書き込んでくれるノートのようなもの。火曜日のキッチンでの会話は何だったか？会議室で実際に何が決まったか？すべての部屋に同時にいることはできませんが、マイクはいられます。

そこで私たちはESP32マイクのフリートをオフィスに配線し、音声をサーバーにストリーミングし、Whisperで処理して、その上にダッシュボードを構築しました。コードネーム：ホートン。ドクター・スースのゾウが埃の粒の上の小さな声を聞くキャラクターにちなんでいます。

1台から複数台へ

ホートンは私のデスクの上の1台のESP32-S3ボードとI²Sマイク（小型マイクの多くが使うデジタル音声バス）から始まりました。それをTCPソケット経由でPythonサーバーに生の音声をストリーミングするように配線しました。サーバーはWhisperを実行し、文字起こしをディスクに保存しました。それがスタック全体でした。動きました。文字起こしは意味を成しました。

1台が動くことの問題は、次に来る明らかな疑問です：これが3台あったらどうなるか？ 次に4台。次に「午後11時と午後3時でキッチンはどう聞こえるか？」 2台以上になった瞬間、もはやデバイスを持っているのではなく——フリートを持っており、フリートについて考える必要があります。

仕組み

ループは小さいです。音声が一方から入り、文字起こしが他方から出ます。

ホートンのパイプライン — 声はマイクからダッシュボードへ旅する

耳、接写

小型のESP32-S3ファームウェアがI²Sマイクから生の音声を読み取り、TCPソケット経由でサーバーに継続的にストリーミングします。サーバーは2つのプロセスを持つFastAPIアプリです：audio_server.pyがTCP音声インジェストを処理し、web_server.pyがダッシュボード、API、ライブフィードを提供します。Whisper（私たちはOpenAIのWhisperのCPU最適化ポートであるfaster-whisperを使用）が文字起こしを行います。GrafanaはサーバーのAPIをデータソースとして使い、ダッシュボードを描きます。

AIパイプラインのための言語を作った理由

Fri, 03 Apr 2026 10:00:00 -0500

昨年3月、エンジニアの一人が壊れたパイプラインのデバッグに40分を費やしました。原因はDOTファイルのバックスラッシュ一文字の欠落でした。その文字は、次のような文字列の中に埋まっていました。

tool_command="set -eu\nmkdir -p .ai .ai/drafts .ai/sprints\nif [ ! -f
.ai/ledger.tsv ]; then\n now=$(date -u +%Y-%m-%dT%H:%M:%SZ)\n printf
'sprint_id\\ttitle\\tstatus\\tcreated_at\\tupdated_at\\n001\\tBootstrap
sprint\\tplanned\\t%s\\t%s\\n' \"$now\" \"$now\" > .ai/ledger.tsv\nfi\n
printf 'ledger-ready'"

これはシェルスクリプトです。bashで6行：ディレクトリを作り、TSVヘッダーがなければ書き込み、ステータスメッセージを出力する。珍しいことは何もありません。しかしDOT属性の中に入れると、改行は \n、タブは \\t、クォートは \" に変わります。スクリプトはそこにあるのに、読めない。自信を持って編集できない。

私たちはTracker——AIパイプラインのオーケストレーションシステム——を開発しています。Trackerは、LLMエージェント・ツール呼び出し・人間のレビュアーが複雑なタスク（コードレビュー、スプリント実行、API設計）に協働する多段階ワークフローを実行します。これらのパイプラインは有向グラフです。プロンプトとモデルを持つノード、条件付きエッジ、リトライループ、並列ブランチ。

私たちはそれをGraphviz DOTで定義していました。

パイプラインが小さいうちはDOTで十分でした。5ノード、シンプルなエッジ、短いプロンプト。しかしパイプラインは成長しました。マルチモデルコンセンサスを持つ20ノードのワークフロー。テストスイートを実行するシェルスクリプト。マークダウンやJSONスキーマを埋め込んだシステムプロンプト。記述フォーマットは「透明な存在」ではなくなり、最も手を焼く相手になっていました。

プロンプトを書くよりも、エスケープ文字のデバッグに時間を取られるようになっていたのです。

DOTが提供できなかったもの

エスケープ文字列の問題は最も目立つ痛点でしたが、唯一の問題ではありませんでした。

DOTはグラフ記述言語です。ノード、エッジ、属性について知っています。しかしAIパイプラインが何であるかは知りません。claude-sonnet-4-6 が有効なモデル名で、claude-sonet-4-6 がタイプミスであるかどうかについて、言語は何も言いません。あるノードが到達不能であること、リトライループに終了条件がないこと、ツールコマンドが存在しないバイナリを参照していること——これらも教えてくれません。こうした問題は本番環境で、パイプラインが失敗したときに発覚します。あるいはもっと悪く、微妙に間違った出力を出し続けます。

パイプラインのテストも別の問題でした。LLM呼び出しは非決定論的なので、その出力をアサートできません。しかし実行の形状はアサートできます：どのノードが訪問されたか、どの順番で、どのブランチが取られたか。それが必要でした。DOTにはそういう概念がありませんでした。

コストの問題もありました。3つのLLMプロバイダーにファンアウトするパイプラインは、3セットのAPI呼び出しを実行します。合計を見積もるには、誰かが手作業でプロンプトトークンを数え、料金表を調べる必要がありました。20のパイプラインに対してそれはスケールしません。

フォーマットから言語へ

バリデーションレイヤーを載せたYAMLスキーマを書くこともできました。しかしバリデーションはエラーを捕まえるだけです——スタイルを正規化するフォーマッター、実行パスを歩くシミュレーター、プロンプトトークンを読むコスト見積もり、エディター上で診断を表示するLSPは手に入りません。そのすべてには、ツールチェーン全体が共有できる型付きデータモデルを生成する文法とパーサーが必要です。

同じシェルスクリプトをDippinで書くと、こうなります。

tool EnsureLedger
 label: "Ensure Ledger"
 command:
 set -eu
 mkdir -p .ai .ai/drafts .ai/sprints
 if [ ! -f .ai/ledger.tsv ]; then
 now=$(date -u +%Y-%m-%dT%H:%M:%SZ)
 printf 'sprint_id\ttitle\tstatus\tcreated_at\tupdated_at\n001\tBootstrap sprint\tplanned\t%s\t%s\n' "$now" "$now" > .ai/ledger.tsv
 fi
 printf 'ledger-ready'

コロンの後にインデントしてスクリプトを書くだけです。エスケープもクォートも \n も不要です。プロンプトにも同じルールが適用されます：ヘッダー、箇条書き、埋め込みコードブロック、JSONの例を含む複数行のマークダウンを、ドキュメントに書くように書けます。

Word Compiler：長編小説のためのコンテキストコンパイラ

Wed, 01 Apr 2026 09:00:00 -0500

問題

LLMで小説を書くことは、フラストレーションとの戦いです。いつの間にかプロンプトエンジニアになっています。システムメッセージを手作りし、コンテキストをコピー＆ペーストし、セッションをまたいでキャラクターの詳細を管理し、モデルが「何を知っているか」を追いきれなくなり、物語がコンテキストウィンドウを超えるにつれて文章の質が落ちていく様子を眺めることになります。既存のツールはLLMをオートコンプリートのように扱っており、クリエイティブなルールに縛られたコラボレーターとしては見ていません。

著者の本当の貢献——声、世界観、物語の意図——は、場当たり的なプロンプトに散らばり、セッションの間に消え去り、次の生成パスに何も引き継がれません。

コンパイラという比喩

Word Compilerはそのアーキテクチャをソフトウェアコンパイラから借用しています。コンパイラはソースコードを読み込み、中間表現を構築し、制約の中で最適化を行い、機械語を出力します。Word Compilerは同じことを散文に対して行います。

コンパイラの概念	Word Compilerの対応物
ソースコード	Bible。キャラクタードシエ、スタイルガイド、場所、物語のルール、禁止フレーズのキルリストを含む構造化ドキュメント
中間表現	Narrative IR。シーンごとのイベント、キャラクターの変化、認識論的状態の抽出
最適化	バジェットエンフォーサー。プロンプトがコンテキストウィンドウに収まることを保証する優先度ベースの圧縮
静的解析	リンター（生成前）とオーディター（生成後）
リンカー	クロスシーンのブリッジング。Narrative IRのキャラクター状態と未解決のテンションによる継続性
コード生成	LLM呼び出しそのもの。唯一の非同期かつコストのかかるステップ

ユーザーはプロンプトを書きません。構造化フィールド（キャラクタードシエ、感情的なビートを持つシーン契約、アンカーライン、サブテキスト契約）を埋めると、コンパイラがコンテキストのペイロードを組み立てます。

実際に何を解決するのか

長編作品のコンテキストウィンドウ問題を解決します。

私たちはLLMに適切なスコープで適切なコンテキストを与える、三リング構造のアーキテクチャを構築しました。

Ring 1（システムメッセージ）はプロジェクトレベルのアイデンティティを担います。声のルール、POVポリシー、文章の構造、語彙の好み、キルリスト、構造的な禁止事項、ポジティブおよびネガティブな例文です。

Ring 2はチャプターレベルの継続性を担います。チャプターのアーク、読者の認識論的状態、アクティブな伏線、過去のシーンのNarrative IRから導出された累積的なキャラクター状態です。

Ring 3はシーンレベルの詳細を担います。シーン契約、発話キャラクターの声のフィンガープリント、感覚的なパレット、アンカーライン、前のチャンクまたは前のシーンからの継続性ブリッジ、アンチアブレーションガードレールです。

合計がトークンバジェットを超えると、コンパイラは圧縮します。最初にRing 1を削り、次にRing 2、最後の手段としてRing 3を削ります。各リング内では、優先度の高い番号から順に、免疫のないセクションを削除します。免疫セクション（キルリスト、構造的ルール、POVポリシー、シーン契約、声のフィンガープリント、アンカーライン、アンチアブレーション）は決して削除されません。

デフォルト設定ではRing 3に最低60%のシェアを割り当てており、40%を下回るとリンターが警告を出します。

10万語の小説は、原稿全体をチャットウィンドウに貼り付けた場合のように第20章で劣化しません。コンパイラは各チャンクが必要とするコンテキストを正確に組み立てます。

プロンプトエンジニアリングなしにクリエイティブコントロールを実現します。

Bibleはスタイルの唯一の真実の源泉であり、バージョン管理されています。すべての編集が新しいバージョンを作成し、古いバージョンに対して生成することをゲートが防ぎます。声の決定、キャラクターの口癖、構造的な禁止事項、キルリストのすべての言葉。すべてが一つのドキュメントに。著者は指示ではなく意図を指定します。

シーン計画も同様に精密です。それぞれが物語の目標、感情的なビート、望む読者への効果、サブテキスト契約（表面的な会話と実際の会話、エンフォースメントルール付き）、アンカーライン（逐語的にマークするか、エネルギーターゲットとして残せる著者が書いた文）、そして避けるべき失敗モードを定義します。コンパイラはそのすべてをプロンプトに変換します。

散文に静的解析と監査を適用します。

生成のたびに、オーディターはBibleに照らして散文をスキャンします。

キルリスト違反：リスト上のすべての単語とフレーズを大文字小文字を区別せずにスキャンします
文章の分散：文の長さの標準偏差が3.0語を下回り、リズム的に単調なパッセージにフラグを立てます
段落の長さ：著者が設定した最大文数を超える段落にフラグを立てます
認識論的リーク検出：キャラクターの知識を過去のシーンのNarrative IRと照合します。キャラクターが学んだことが一度も示されていないことに言及した場合、フラグが立てられます
伏線/回収の追跡：シーン計画で埋め込まれるまたは回収されると言われていたことと、IRが実際に起きたと言っていることを比較します。原稿完成時に、一度も解決されなかった伏線にフラグが立てられます
サブテキストコンプライアンス：散文とシーンのサブテキスト契約をモデルに送り、いずれかのキャラクターが言外の意味を明示的に口にしていないかチェックします

これらはリンティング、型チェック、インテグレーションテストの散文版です。未解決の重大な監査フラグは、ワークフローゲートを通じてシーンが進むのをブロックします。警告と情報レベルのフラグは進行をブロックしませんが、著者が解決または却下するまで表示され続けます。

構造化された制約を通じて声を構築します。

Word Compilerにおける声とは、すべてのプロンプトにコンパイルされる重層的な制約です。Bibleはキャラクターレベルの声のフィンガープリント（語彙のメモ、口癖、比喩的なレジスター、禁止言語、対話のサンプル）とプロジェクトレベルのスタイルルール（ポジティブおよびネガティブな例文、文章の構造、比喩的な領域、語彙の好み）を持ちます。Ring 1はこれらをシステムメッセージに組み立てます。Ring 3はシーン内の発話キャラクターすべてのキャラクターレベルの声のフィンガープリントを注入します。

著者がコントロールを保ち続ける方法

すべてのステージで決定権は著者の手にあります。

あらすじを貼り付ければ、システムがドラフトのBible（キャラクター、場所、トーン、キルリスト）を生成します。あるいはすべてをゼロから構築することもできます。すべてのフィールドは編集可能です。Bibleはあなたのものです。

シーン計画には、人間のストーリーテラーだけがうまく埋められるフィールドが含まれています。サブテキストフィールドは、キャラクターが表面上何を話しているかと実際に何を伝えているかを、エンフォースメントルール付きでキャプチャします。アンカーラインは著者が書いた特定の文で、逐語的に表示されなければなりません。失敗モードは何を避けるべきかを述べます（「どんでん返しを電信するな」「メロドラマ的な台詞はなし」）。

生成はチャンクごとに進みます。各シーンの目標語数（著者が設定可能で、デフォルトは800〜1200語）は、一定数のチャンクに分割されます。著者はそれぞれを確認し、承認、編集、または却下とマークします。編集こそが本当の著者活動が起きる場所です。学習器は監視しており、AIが書いたものと著者が残したものの差分を分析し、編集のタイプを分類しています：フィラーの削除、トーンの変化、「見せろ、言うな」への置換、感覚的な追加。

著者はすべての監査フラグを、対応可能または却下としてマークすることで解決します。解決データはカテゴリ別に監査の品質を経時追跡するシグナル対ノイズ指標に供給されます。自動修正は何もありません。

シーンが完成すると、システムは起きたことの構造化された表現を抽出します：イベント、導入された事実、読者に明かされた事実、隠された事実、キャラクターの変化、植え込まれた伏線、実行された回収、キャラクターの位置、未解決のテンション。記録は未検証の状態から始まります。著者はそれがクロスシーンの継続性に供給される前にレビューして確認します。

リビジョン学習器からのBible提案とパラメータアナライザーからのチューニング提案は、著者が承認または却下するまで保留状態で届きます。システムが提案し、著者が決定します。

AIアシストコーディングから借りたアイデア

私たちはコードについて考えるのと同じ方法でこれを構築しました。

3DプリンターをAIポートレートアーティストに変えた話

Fri, 20 Mar 2026 09:00:00 -0500

古い3DプリンターにペンをくくりつけてAIにPicassoを模倣させたら、どうなるでしょうか。その場で肖像を描いてくれるフォトブースができあがりました。これが「Micasso」です。

埃をかぶっていたプリンター

オフィスの隅に3Dプリンターが放置されていました。そろそろオープンハウスが迫っていて、パーティーを盛り上げる何か楽しいもの——持ち帰れる、物理的な何か——が欲しかったのです。アイデアはシンプルでした。写真を撮って、AIに線画に変換してもらい、プリンターにペンで描かせたらどうだろう、と。

私たちが惹かれたのはデジタルとアナログのループです。AIが画像を画面上に生成するのは当たり前ですが、そのあとに機械が実際にカードに描くのを目の前で見られる。ペンが自分の顔をなぞる瞬間には、画面では味わえない何かがあります。

Micassoの近影 — ペンホルダー、InspireボタンとRealizeボタン、そして描きたての肖像

InspireとRealize

インタラクションには2つの瞬間があり、それぞれに意図を込めて名前をつけました。

Inspireボタンを押すとカメラが準備を始め、カウントダウンが流れ、シャッターの瞬間にブースが*「Micassoooo」*と叫びます——シャッター音であり、個性でもあります。

撮った写真が画面に表示されます。気に入らなければInspireをもう一度押して撮り直せます。準備ができたらRealizeを押す——インスピレーションを現実にする瞬間です。AIが肖像を生成し、コードがペンのパスに変換し、約30秒後にプロッターが描き始めます。

待っている間、画面には俳句が表示されます：

ロボットが顔を学ぶ
数字が詩になる
機械の言葉が語られる

仕組み

パイプラインは5ステップです。写真を入れると、ペンで描かれた肖像が出てきます。

Micassoの処理パイプライン

Raspberry Pi 5に接続したウェブカメラが写真を撮影します。その写真はAI画像モデル（OpenAI、Google Gemini、またはセルフホスト版に対応）に送られ、PicassoとMiróのスタイルを模した最小限の線画に変換されます。AIの出力はベクターパスにトレースされます——これについては後述しますが、ここで少々ハマりました。そのベクターはvpypeを使ってアーク補正付きのG-codeに変換されます。G-codeはレシピのようなものです：ここへ移動、ペンを下ろす、この線を引く、上げる、あそこへ移動。そしてプリンターがペンを持って描き始めます。黒い6×4インチのカードに白いペンで。

詰まったところ

物理ペンのためのプロンプトエンジニアリング

画面向けのプロンプトエンジニアリングと、物理ペン向けのそれはまったく別物です。AIはグラデーションなし、塗りつぶしなし、線幅の変化なしで——機械ペンが再現できるクリーンなストロークだけで——アートを生成しなければなりません。

私たちはかなり試行錯誤しました。最終的にたどり着いたのがこちらです：

PORTRAIT_PROMPT = """Transform this photo into a minimalist single-line portrait
in the style of Picasso and Joan Miró.

Requirements:
- Single continuous stroke aesthetic (the drawing should look like it could be
 drawn without lifting the pen)
- Uniform line thickness throughout - no variation, shading, or hatching
- Abstract but recognizable - simplified eyes, nose, mouth, hair
- Minimal clothing suggestion - as few strokes as possible
- Clean white background with no texture or marks
- Black lines only on pure white
- Empty white space around the portrait
- Gallery-style minimalist aesthetic

The result should look like modern minimalist line art suitable for pen plotting"""

すべての言葉が重要です。「Single continuous stroke aesthetic」と「uniform line thickness」という表現が、画面映えするものとペンで実際に描けるものとの分かれ目になります。

シマー：自己研磨スキル

Fri, 13 Mar 2026 14:00:00 -0500

バークレーの研究者たちは、出力を評価し優先順位付きの実行可能なフィードバックを与えられる限り、RLスタイルのフィードバックループをあらゆるテキストタスクに適用できることを示しました。彼らはこれをActionable Side Information（ASI）と呼んでいます。目標は次に何を改善すべきかに焦点を当てたフィードバックです。APIなら「POSTエンドポイントにエラーレスポンスがない」かもしれません。ストーリーなら「第二段落でペーシングが落ちる」かもしれません。生成器が散漫にならずに行動できるほど焦点が絞られていることが必要です。

私たちはこれをシマーというClaude Codeスキルとして構築しました。何を洗練させるか、「より良い」ための基準を定義します。エージェントが生成し、それらの基準に対して評価し、優先順位付きの修正をフィードバックして繰り返します。テキスト形式のものなら何にでも機能します。アドベンチャーフック、ピッチメール、API仕様、ブログ記事。

次に私たちはシマーを使って、シンプルな内側/外側のエージェントループを使いながらシマー自身を研磨させてテストしました。外側のループ：スキル定義のバージョンを取り、どれだけうまく機能するかを評価し、ブレークポイントを見つけ、スキルを改善して繰り返します。各バージョンで内側のループ：そのスキル定義とテストタスクのセットで3つのエージェントを起動し、各エージェントがそれらのタスクを独立してシマーし、結果を比較します。3回の外側のイテレーション。これが何を教えてくれたかを紹介します。

審査員はキャリブレーションがないと膨らませる

最初の内側の実行で、スコアの軌跡を確認すると全員が9.2を記録しており、実際のテキストを読むまでは素晴らしく見えました。極めて具体的な基準なしには、各サブエージェントの審査員がスコアを膨らませていました。例えば3回目のイテレーションのアドベンチャーフックにはまだ受動的なヴィランと賭けるものがなく、説得力あるD&Dアドベンチャーモジュールになっていませんでした。

審査員は、どこから始まったか、スコアが何を意味するかの記憶がなかったため、寛大なスコアに流れていました。修正方法は、シードアーティファクトとそのイテレーション0のスコアを毎ラウンドの永続的なコンテキストとして審査員に与え、さらに各スコアレベルが何を意味するかの明示的なアンカーを追加することでした。それを加えると、スコアが一貫して、実行を通じてより方向性の正しいものになりました。

スキルはアーティファクトよりも速く改善した

内側のループの結果は外側のイテレーションを通じて改善しましたが、アーティファクトが劇的に変化したからではありませんでした。アドベンチャーフックとAPI仕様は最初の実行から真に良いものでした。時間をかけてスキルで主に改善されたのは、私たちには明確に見えた指示がエージェントには曖昧に見えたということを、イテレーションが特定するのを助けたことです。「デフォルト3イテレーション」は3つの異なるイテレーション数を生み出しました。「軌跡を記録する」は3つの異なるテーブルスキーマを生み出しました。修正は常に同じでした：指示を明示的な契約に置き換えること。3回目の外側のパスまでに、内側のループの3つのエージェントすべてが同じプロセスに従い、比較可能なスコアを生み出し、独立して同様の品質レベルに到達しました。この実験的なループでシマーが自分自身を研磨させることで、サブエージェントの実行とフルパイプラインの実行がより一貫したものになりました。

なぜ機能するか

従来のMLでは、フィードバックループは何千回ものイテレーションを通じて潜在空間をランダムウォークして解を近似することを意味します。私たちのエージェントではそれをする必要がありません。バックボーンのLLMは大規模な事前学習済みの能力とほとんどのトピックへの確かな理解から始まります。モデルは良いAPI仕様がどのようなものかを、説得力あるアドベンチャーフックがどのように読めるかをすでに知っています。ゼロから探索する必要はありません。この特定のアーティファクトに何が欠けているかを指摘する人が必要なのです。それがASIメカニズムを実用的にするものです。焦点を絞ったフィードバックと有能なエージェントがあれば、3,000回ではなく3〜5ラウンドで収束します。

試してみる

シマーはClaude Codeのプラグインです。

/plugin marketplace add 2389-research/claude-plugins
/plugin install simmer

クックオフ：同じ仕様、異なるコード

Thu, 12 Mar 2026 10:00:00 -0500

計画は敵と接触した瞬間に崩れる。誰でも殴られるまでは計画を持っている。好きな言い方を選んでいい……要点は同じです。計画は抽象であり、抽象は現実に完全には写像されません。定義上、複数の有効な実装を許容するものです。

しかしAIはこれをより無視しづらくします。「明確な仕様」と「正しい実装」の間のギャップが、かつて一つのバージョンを生み出すのにかかっていた時間で、真に異なる実装を複数生み出せるようになったからです。最初の「正しい」実装だけを見ていると、有用な情報を取りこぼしている可能性があります。

その空間をすぐに一つに絞らず、探索してみたらどうなるでしょうか？

私はそのアイデアを突き詰め、モデルのばらつきを特徴として活用するためにクックオフを書きました。

Same spec, different implementations

セットアップはシンプルです。同じ設計書。複数のエージェント。独立した環境。並列ビルド。そして返ってきたものを評価します。

評価は単純に「どれが動くか」ではありません。「それぞれが何を最適化したか」です。どんな前提が埋め込まれたか？一方にはあって他方にはなかった防御的な処置は何か？どのソリューションが適切な意味でシンプルで、どれが単に薄いだけか？

私たちはクックオフを使って、Bubble Teaを使ったチャットクライアントのTUIを構築しました。3つのエージェントが同じ仕様を受け取りました。3つのエージェントが同じフレームワークに対してビルドしました。返ってきたものはノイズではありませんでした。実装空間の小さな地図でした。

一つのバージョンは生のHTTPとフラットなモデルを使っていました。もう一つはネストされたコンポーザブルモデルを採用し、カーソルクランプ、送信者フォールバックロジック、タイムスタンプガード、その他の品質向上のための堅牢化といった防御パターンを多数含んでいました。審査員が結果を採点したところ、25点中18点で同点でした。

この引き分けこそ、私がこのパターンを気に入っている理由の一つです。経験的な「最良」の実装というものは存在しません。あるのは最適適合、今のための最良、これらの制約のもとでの最良です。実装を一つの正解を探す行為として扱うことは的外れです。有用な結果は多くの場合、複数のアプローチが異なる理由で擁護できるということであり、真の価値はそれらを学んでこのコンテキストにおいて最善のものへとまとめることから生まれます。

この場合、タイブレーカーはテスト数と本番行数の少なさからシンプルな実装を支持しました。それは良いことです。そのバージョンが勝者になりました。しかし「負け」の実装には勝者にはなかった防御パターンがありました。貼り付けのレースコンディション修正。UTF-8安全なトランケーション。ゼロタイムスタンプガード。

そこで私たちはそれらのアイデアを拝借しました。

これが本当の成果です。クックオフは単にチャンピオンを決めるためのものではありません。一つのコードベースに戻る前に、分岐から学ぶための方法です。最終結果は単一の候補よりも優れたものになり得ます。なぜなら、一つのエージェントの選択に付随する偶然のバンドルを受け入れる必要がないからです。

今回のケースでは、より強力な防御パターンをシンプルな勝者に移植し、いずれの実装単体よりも優れた最終コードを得ました。

これは非決定性についての私の考え方を意味のある形で変えました。一つの答えだけを求めるなら、非決定性は抑制すべき問題に見えます。出力を賢く比較し、ニュアンスの中で活躍できるなら、非決定性は探索になります。

もちろんコストはあります。複数の実装を実行することは一つを実行するよりも費用がかかります。しかし「負け」のランから得られるアイデアを持ち帰ることで、それらの欠点を後から一から対処する必要がなくなり、コストを回収できます。あるいはもっと悪いことに、本番環境で失敗してから対処するということもなくなります。実装の詳細が重要で、失敗の形を事前に予測するのが難しいときこそ、比較のコストを支払う価値があります。

また、失敗の感覚も変わります。一つの実装が崩れても、ゼロには戻りません。すでに探索空間をより多く購入しています。他に何が試みられたかを知っています。すでに代替パスを手元に持っているかもしれません。それは品質にとって有用なだけではありません。モメンタムにとっても有用です。

不確実性のすべてが前倒しではありません。その一部は明確な方向性が出た後も残ります。一部は実際のコードが書かれて初めて現れます。クックオフはその層のためにあります。オマカセが反応するためのアーティファクトを与え、デリベレーションが一緒に考えるための視点を与えるのと同じように、クックオフは比較するための実装を与えます。

同じテーマ、異なる反応の対象。

私はばらつきを隠してコンパイルできる最初のものを返すだけのAIコーディングシステムは求めていません。その差異が重要なときに、意味のある違いを検査できるシステムを求めています。勝者が答えになることもあります。答えの広がりが答えになることもあります。

試してみる

クックオフはClaude CodeのTest Kitchenプラグインの一部です。

/plugin marketplace add 2389-research/claude-plugins
/plugin install test-kitchen

オマカセ：見せてくれ

Thu, 12 Mar 2026 09:30:00 -0500

具体的に反応できるものが手元にあるまで、自分が何を求めているかわからないことがあります。Claudeがその前に選択を求めてくると、作業を進めるためだけに好みを作り上げてしまいがちです。うまくいくこともあります。しかし、実在しなかった答えを巡って空回りを生むこともあります。

そのためにオマカセを作りました。アイデアはシンプルです。方向性の選択に行き詰まっているなら、Claudeが具体的なバリアントを構築し、本物の反応対象を与えます。トレードオフの箇条書きでも、長所と短所について整然とした段落でもなく。実際に見て、使って、評価できる実装を。

UHFで盲目の男性がルービックキューブを解くシーンがあります。これはそんな感じです。Claudeがキューブをいじります。私は色が合っているかどうかを告げます。パーツがどう合わさるべきかわからなくても、目の前のものが間違った形をしているときは大抵わかります。

Claude showing me what I want before I know how to ask for it

一つの小さな例でその価値が明確になりました。

カレンダービューをCLIアプリに追加していました。大きな製品上の決断ではありませんでした。「カレンダービューがあるべき」と感じるほど簡単なはずの機能でしたが、実際には持っていないビジュアルの好みがあるふりをしていることに気づいた段階で、そうでもなくなります。アジェンダにすべきか？囲まれた週ビューか？カウント付きの月グリッドか？基準を作り上げることに一時間費やして、その結果を正当化することにさらに何時間も費やしかねませんでした。

代わりに私は言いました：omakase it。

Claudeが3つの異なるアプローチを並列で構築しました。今日と明日のラベル付きシンプルな時系列アジェンダ。より強い視覚的グルーピングを持つ囲まれた週ビュー。ドリルダウン付きASCII月カレンダー。それぞれ、スケッチではなく本物の候補として感じられるほど十分に構築されていました。

それらを見た瞬間、意見が結晶化しました。

アジェンダビューが正しかったのです。週ビューは賢いが騒がしかった。月グリッドは楽しかったが、カウントだけでは有用ではありませんでした。タスク名が必要でした。これらの判断はどれも、事前に書き下せる形では存在していませんでした。反応できる何かができて初めて明らかになりました。

これがオマカセのコアバリューです：意思決定をアウトソーシングするのではなく、意思決定を判読可能にすることです。

最初の選択が壊れるとき

常に使っています。同じ機能で複数回使うこともよくあります。macOSのドットファイルビューアーを構築していて、エディタがSVGプレビューとどう関係すべきかで必要以上に時間を費やしました。実装が不可能だから行き詰まっていたのではありませんでした。現在のアプローチが擁護できるほど近く、満足できないほど間違っているから行き詰まっていたのです。オマカセが2つのクリーンなアーキテクチャオプションを与え、私はその形に反応し、一つを選び、空回りが止まりました。

そのプロジェクトのもう一つの例は、エディタに行番号を追加することでした。

Variant A — NSTextView subclass (LineNumberTextView.swift)
- Subclasses NSTextView, draws gutter in draw(_:) override
- Uses textContainerInset + manual text container sizing to avoid the invisible text bug
- Provides scrollableLineNumberTextView() static factory
- Simplest integration - swap one line in EditorView's makeNSView()

Variant B — NSRulerView (LineNumberRulerView.swift)
- Subclasses NSRulerView, draws in drawHashMarksAndLabels(in:)
- Static installation / pinned to the scroll view
- Minimal integration: add one line after scroll view creation
- Apple's recommended approach for gutter content

Variant C — Side-by-side NSView (LineNumberGutterView.swift)
- Standalone NSView, syncs via scroll view bounds notification
- Not integrated into scroll view internals → adds a composition layer
- Most isolation: doesn't touch text view internals at all

My take: B is the cleanest — one-line integration, uses Apple's built-in infrastructure

行番号への3つのアプローチ。私はこれの約30%しか理解できませんでした。それで問題ありませんでした。

デリベレーション：答えではなく、視点を

Thu, 12 Mar 2026 09:00:00 -0500

ツールが早すぎる選択を迫ることで、悪化する意思決定があります。

それは逆説的に聞こえます。現代のAIワークフローのセールスポイントは、選択肢を明確にし、曖昧さをメニューに変換し、意図を具体的な次のステップに変換することで、私を速く動かすことです。たいていはそれがまさに私の求めるものです。

しかし、メニューにする準備ができていない意思決定もあります。

私にとって最も重要な意思決定は、最初は半分しか形成されていないことが多いです。問題を明確に述べた文章と、許容できる答えの優先順位付きリストを持って来ることはありません。漠然とした苛立ちや、ぼんやりとした興奮、あるいは何かがほぼ正しいのに実際には正しくないという感覚を持って来ます。その段階で早すぎる選択をすると、問題の間違ったフレーミングを最適化することになりがちです。

これは特定のクラスの不確実性です。「何も考えがない」のではなく、「自分の考えがまだ信頼できるほど熟していない」状態です。問題が判断するために具体的なバージョンを見る必要があること、あるいは実装を比較する必要があることであれば、それらは別のツールです。これは、問いそのものがまだ形を成しているそれより前の段階についてです。

素早く意思決定できる人がいます。選択肢を見て、一つを選び、動く。そういう人と一緒に仕事をしています。時々羨ましくなります。私はそういう人ではありません。私の最善の意思決定は、少し時間をかけて問題を様々な角度から眺め、自分の反応が鋭くなり始める場所に気づくことから来る傾向があります。問題は、熟成が遅く、残りのワークフローはスピードのために作られているということです。

それがデリベレーションの目的です。

デリベレーションは私のために問いに答えようとしません。問いに関わりを持つ視点の委員会を組み上げ、私が聴く間に一度に一人ずつ発言させます。構造が重要です。私はそこで議論するためにいるのではありません。採点するためにいるのでもありません。リアルタイムで応答するためにいるのでもありません。要点は、好みの答えを急いで擁護する前に反応を起こさせることです。

これが焦点を結んだ最初の瞬間は、大学進学探索アプリを構築している最中でした。

私はそのためのチャットインターフェースを設計していました。技術的には設計は問題ありませんでした。永続的なウィジェット、ページスコープの会話、見直されたオンボーディングフロー、そして自信を持って実行に送り込めるほど十分な実装詳細がありました。実際に送り込みました。でも、ずっといじり続けていました。調整また調整。確信なし。着地なし。何かが間違っていたのですが、それが何なのか言葉にできませんでした。

アウトプットがないから詰まっていたのではありません。すべてのアウトプットが少し説明しすぎていて、少し死んでいたから詰まっていたのです。

そこでデリベレーションセッションを実行しました。

You've been thinking about this — you have a perspective, not just a question.
Let's discern this together.

A few ground rules:

You speak once. Not once per topic — once total. So wait until you have
something that really needs to be said.

You don't have to speak. Silence is not awkward here. If you have nothing to
add, that's meaningful.

Don't react, discern. The urge to respond to each point is normal. Resist it.
Sit with what's shared. If something genuinely arises, share it. If it's just
reaction, let it pass.

This is slow, and that's the point. We're not optimizing for a quick answer.
We're making space for clarity to emerge.

I'll check in with you at natural moments. "Continue" is always a valid answer.

---

The question we're discerning: How should the chat interface work in College
Compass — its form, its relationship to the pages, and its role in the overall
experience?

For perspectives alongside yours, I'd suggest:

1. The Parent — someone using this while juggling work, driving kids around,
stealing 5 minutes here and there
2. The UX Pragmatist — thinks about what actually works in widget-style chat
interfaces (what Intercom got right and wrong)
3. The Data Architect — thinks about conversation scoping, context passing, and
what happens to the information in these chats

Anyone you'd add or change?

委員会の招集

ダークファクトリーは .dot ファイルだった

Mon, 09 Mar 2026 12:00:00 -0500

StrongDM がコーディングエージェントのパイプラインランナーを構築するための自然言語スペックを公開した。Dan Shapiro がひとつ作った。私たちはさらに 3 つ作った。それらすべてが——独立して、2 つの言語で、異なる目標を持つ異なる人々によって——同じ 3 層アーキテクチャに行き着いた。

このことが頭から離れない。コードではなく、収束のほうが。それが不思議な部分だ。

アトラクターパターン

2 月に StrongDM は attractor をオープンソース化した。統一 LLM クライアント、コーディングエージェントループ、DOT ベースのパイプラインエンジンを記述した 3 つの自然言語スペックだ。スペックはコードではない。散文だ。約 5,700 行。コーディングエージェントに渡して「これを作って」と言えるほど詳細に書かれている。そして実際に作れる。

名前はダイナミカルシステムから借りた——アトラクターとは、システムが収束しようとする状態のことだ。StrongDM の賭けは、これらのスペックが問題に対して非常に自然な設計を記述しているため、独立した実装が同じ場所に収束するだろう、というものだ。大胆な主張だが、実際にそうなった。

彼らはまた AttractorBench もリリースした。コーディングエージェントが自然言語スペックからシステムをどれだけうまく実装できるかを測定するベンチマークだ。段階的になっている——スモークテスト、統一 LLM SDK、コーディングエージェントループ、フルパイプラインランナーの順に進む。言語非依存で、エージェントが実装言語を自分で選ぶ。唯一の契約は make build、make test、そしてモック LLM サーバーに対するコンフォーマンステストスイートだ。実際の API 呼び出しはない。決定論的な検証。コストを意識したスコアリング。「作れたか？」を問うだけではなく、「スペックにどれだけ忠実に従い、コストはいくらかかったか？」を問う。

Dan Shapiro はしばらくこの進歩について考えていた。1 月に彼は “The Five Levels: from Spicy Autocomplete to the Dark Factory” を公開し、NHTSA の運転自動化レベルを AI 支援コーディングに当てはめた。レベル 0 は vi だ。AI なし。すべての文字は自分のもの。レベル 2 は今の「AI ネイティブ」開発者のほとんどが生きている場所——モデルとペアプログラミングをして、生産性を感じている。レベル 4 では PM になっている。スペックを書き、スペックについて議論し、12 時間離れて、テストが通るか確認する。

レベル 5 がダークファクトリーだ。照明オフ。誰もコードをレビューしない。誰も見すらしない。

「ダークファクトリー」という言葉は製造業から来ている——ロボットが照明なしで動かすファクトリー。ロボットは見る必要がないからだ。具体的には、日本の Fanuc Robotics が 2003 年頃に実践したものだ。

Week 0 NVIDIA DGX Spark 実験レポート

Tue, 28 Oct 2025 09:00:00 -0500

ある日、出社すると Harper（私たちの CEO）から「この NVIDIA Spark ボックスで何ができる？」と聞かれました。当時はまだリリース前だったので、正直なんのことか全く分かりませんでした。でも少し調べてみると、コンパクトなボディに 128GB の統合メモリを詰め込んだパッケージはなかなか面白いものだと気づきました。

It is very very gold and shiny

データサイエンティストとしてここ十年ほどはニューラルネットワークの学習に多くの時間を費やしてきましたが、その最大の制約のひとつが GPU RAM でした。古い 1070/1080 カードから自前の 4090、業務用の A10 や H100 まで様々使ってきました。一般的な作業なら H100 でも十分こなせますが、128GB という容量をこのサイズの筐体で社内に持てるのはかなり新鮮です。Spark ボックスがどこまでやれるか確かめるために、いくつかのテストを実施することにしました。1. Ollama 経由で Llama 4 モデルをテキスト生成タスクに使い、128GB RAM を積んだ私の M4 Apple Silicon Mac と速度比較する。2. 新しい DeepSeek OCR モデルを動かせるよう設定する。3. Llama 3.1 70B モデルへの LoRA アダプターを学習させる。生成という基本的なパイプラインから、互換性トラブルシューティングが伴う新モデルの導入、そしてこれまでは自分では到底学習させられなかった規模のモデルを使ったトレーニングランまで、バランスよくカバーできるテスト内容だと思いました。## 「Hello World」— NVIDIA Spark で Llama 4 を動かす接続環境を整えてシステムに慣れてきたころ、Meta の Llama 4 モデルを引っ張ってきて基本的なテキスト生成を試してみることにしました。Ollama と OpenWebGUI のインストールと起動はかなりスムーズで、パイプラインが十分文書化されていたおかげで所要時間は約 60 分ほど。そのほとんどは自分のミスで Llama 4 モデルを何度もダウンロードし直した時間です。選んだのは Llama 4 Scout モデルで、109B パラメータのうち任意の時点でアクティブになるのは 17B パラメータのサブセットです。モデルをダウンロードして実行したところ、予想どおり約 67GB のメモリを使用していました。NVIDIA のダッシュボード上ではメモリが全量割り当てられているように見えましたが、他の診断ツールで確認すると実際は想定どおりの 67GB 程度でした。

Nvidia DGX Spark memory usage dashboard

ブレインダンプからブログ記事へ

Wed, 12 Mar 2025 09:00:00 -0500

LLM を活用して学んだことをドキュメント化する方法

今日のスピード感あふれるソフトウェア開発の現場では、革新的なソリューションやベストプラクティスが、断片的なメモ、場当たり的なコミット、行き当たりばったりのトラブルシューティングに埋もれがちです。

私も多くの開発者と同じく、最初のブレインストーミングから最終的な解決策に至る全工程を記録するのは難題でした。ところが開発の各段階で LLM（Large Language Model）を使うようになってから、堅牢なシステムを構築するだけでなく、未整理のアイデアを分かりやすいドキュメントにまとめられることに気づいたんです。

こうして生まれたドキュメントは、あなた自身や チーム、組織、さらには コミュニティ全体 の学習を加速させる貴重なリソースになります。

本記事では、ここ数か月で練り上げてきたワークフローを紹介します。ただの「LLM でより良いコードを書くためのガイド」ではありません。これは 行動を促す呼びかけ です。ぜひあなた自身のプロセスを作り、洞察をドキュメント化し、共有してみてください。継続的に更新される知識ベースが生まれ、みんなで育てていけます。

LLM 活用ワークフローの概要

このワークフローは、次の 5 つのフェーズから成ります。

調査 / Researching — データの収集と統合
意思決定 / Deciding — 代替案の評価と方針策定
構築 / Building — AI ツールを使ったコーディング
反復 / Iterating — テスト・デバッグ・改善
文書化 / Documenting — 洞察と判断を整理しドキュメントにまとめる

もちろん、これらのステップそのものは目新しいわけではありません。Harper のような人たちは昔から似たプロセスで開発しています。

私が声を大にして伝えたいのは、最後の 文書化 までやり切り、得た知見を誰もが読めるハンドブックとして結晶させようという点です。

この反復的なワークフローによって、ドキュメント自体が常に更新される 生きた資料 となり、問題解決のあらゆる側面が循環して知識ベースを豊かにしていきます。

以下は、この継続的プロセスの高レベル図です。

 flowchart TD
 A[調査 / Researching] --> B[意思決定 / Deciding]
 B --> C[構築 / Building]
 C --> D[反復 / Iterating]
 D --> E[文書化 / Documenting]
 E --> F[共有学習リソース / Shared Learning Resource]
 F --> A

図: 各フェーズが次を後押ししながら循環し、最終的にコミュニティ全体に役立つリソースへとつながるサイクル。

GraphRAGの実験：RAGパイプラインにナレッジグラフを追加する

Thu, 06 Mar 2025 09:00:00 -0500

最近、私たちのチームでは Microsoft が提案する GraphRAG と LazyGraphRAG の要素を取り入れ、実験的に実装を行っています。これらのアプローチは、従来の検索拡張生成（Retrieval-Augmented Generation: RAG）システムが苦手としてきた「コーパス全体を俯瞰する高次の理解」が必要なクエリに対し、有望な解決策を示してくれます。

RAG システムの問題領域

同僚いわく、LLM は一般知識の保持と文章生成は得意だけれど、特定ドメインの文脈知識が抜け落ちている──まさにそのとおりです。そのギャップを埋める代表的手段が RAG で、セマンティック検索などを使って関連情報を取り込み、クエリ回答に活用します。

私自身、LLM にナレッジベースを組み込む必要があるときは、EC 企業で検索パイプラインを作っていた頃と同じように、既製モデルやファインチューニング済みモデルでベクトルデータベースを検索し、必要なら外部ツールで最新情報を取得するやり方を採ってきました。

この方法は、ChatGPT が登場した当初に目立っていた深刻な幻覚をかなり抑えてくれました。たとえば特定のレシピを尋ねられた場合、該当レシピをデータベースから取得して LLM に渡すだけで、ドメイン固有の知識に集中して回答を生成できます。

従来型 RAG の限界

従来型 RAG は具体的なクエリには強いものの、抽象的で俯瞰的な問いにはめっぽう弱い――大統領令のコーパスで試すと、その差は歴然でした。

「2023 年に移民取り締まりを扱った大統領令は？」のような具体的な質問なら、関連文書や抜粋をきちんと返してくれます。
ところが「すべての大統領令に共通する主要テーマは？」「政策の優先順位は時系列でどう変化した？」といった俯瞰的な質問になると、まるで役に立ちません。

理由は単純で、従来型 RAG はクエリと“響きが似ている”文書を探すだけだからです。たとえば「主要テーマ (major themes)」という語に引っ張られ、「Major changes to ICE」や「スギ少佐 (Major Sugi) が昇進」など、単に “major” を含む無関係な文書を拾ってしまい、その歪んだデータセットを要約してしまうわけです。

後からどれだけ要約を工夫しても、もはや軌道修正はできません。最初に概念の全体像を見ていない限り、手遅れなのです。

こうした欠点は、大規模コーパスを俯瞰して理解するタスクで特に顕著であり、まさにそこで Microsoft の GraphRAG などの新技術が力を発揮します。

GraphRAG: Microsoft のグラフベース手法

Microsoft の GraphRAG は、公開論文で提案された手法で、知識グラフを用いた情報検索によって LLM の知識ベースを拡張します。大まかな流れは次のとおりです。

コーパスを用意する（インターネットテキスト、商品カタログ、大統領令など）。
LLM でエンティティとリレーションを抽出し、知識グラフを構築する。
グラフにコミュニティ検出（クラスタリング）をかけ、高レベルのグループ化を行う。
各コミュニティに含まれるデータをまとめ、要約を生成する。
ユーザーがクエリを出すと、ノードレベルとコミュニティレベルの情報を組み合わせて回答する。

コミュニティレベルの情報がノード群とその入力データを丸ごと保持しているため、LLM は集約作業を減らし、生成に専念できます。

LazyGraphRAG: より効率的なアプローチ

続いて Microsoft が発表した LazyGraphRAG は、LLM 呼び出し回数を最小化する実装です。

自己学習型LLMエージェント：ドメイン固有知識へのフラクタルアプローチ

Wed, 08 Jan 2025 09:00:00 -0500

トレーニングを通じて LLM は高い言語理解能力を身につけますが、学習データは取得時点で固定されるため、それ以降に発生した知識を参照できません。また、モデルは幅広い領域で“そこそこ万能”な性能を発揮するよう最適化されているため、広く浅い知識にとどまりがちです。

そのまま使うと、LLM が返す回答は汎用的かつ表層的になりやすいものです。早い段階から「言語理解は LLM に任せ、専門知識は別系統で補う」というパラダイムが定着し、Retrieval Augmented Generation（RAG）が主流になりました。ドメイン固有の知識をベクトル化して保管し、検索で呼び出す手法です。

この手法により LLM に深いドメイン知識を付与できるようになった一方で、自己相似的な “フラクタル問題” も生じます。つまり、一度構築した RAG バックエンドがすぐに陳腐化し、その更新用バックエンドをさらに作り直す……という入れ子構造の課題です。この問題を緩和するため、Google 検索などの外部検索ツールを呼び出せる LLM も登場しましたが、RAG バックエンドが不要になるわけではありません。せいぜい数件の Google 検索で得られる情報をはるかに超える深い専門知識を保持できるからです。

2389 では、未来はマルチエージェント型だと考えています。単一の巨大エージェントではなく、ユーザーは数百〜数千のエージェントと気軽に対話するようになるでしょう。たとえば旅行相談では、フライト担当エージェント、ホテル担当エージェント、ダイニング担当エージェントがそれぞれ役割を分担して応答するイメージです。

エージェントは学習できるのか？

大きな理論的課題は「多数のエージェントにどうやって領域特化の知識を持たせるか」です。従来のナレッジベース構築は個別に制作・保守しなければならず、スケールしません。

私がとくに興味をもっているのは、エージェント自身に“完全な裁量”を与えて好きなように学ばせる方法です。最小限の初期入力だけで、時間とともに独自の専門知識を育て、ユーザーの興味に合わせて適応できるか。基盤となるエージェントは共通でも、ユーザーごとに応答スタイルだけでなく内部知識まで変われば大きな価値があります。

本稿では、自己学習エージェントに関する最近の実験を 2 つ紹介します。

自律ナレッジベース生成
わずかな初期入力から、任意のトピックについてエージェント自身がナレッジベースを構築できるか。
対話駆動型の知識拡張
直近の対話を振り返り、知識ギャップやユーザーの関心を検出して情報を収集し、ナレッジベースを拡張できるか。

LLM エージェントのフラクタル特性

今回の試みは、Google Co-Scientist や Agent Laboratory 論文などから着想を得ています。いずれも複数エージェントが「生成 → 評価 → 改良」のサイクルを多段で回すフラクタル（自己相似）的設計です。たとえば Co-Scientist ではアイデアを生成し、別エージェントが採点し、さらに洗練する過程を繰り返します。Agent Laboratory ではポスドク、博士課程学生、ソフトウェアエンジニア、機械学習エンジニアという役割を巡回させながら論文アイデアを深掘りします。

私は EC 業界でバックエンド向けセマンティック検索を長年担当してきました。GraphRAG などを含む RAG バックエンドの実装でも「フラクタルなセマンティック検索」という考え方が基盤にあります。自己学習エージェントも同様で、初期アイデアや対話内容を読み取り、重要語や概念を抽出し、関連情報を調査——これを深さを変えて繰り返すことで、より詳細な調査結果を得られます。

ゼロから“ヒーロー未満”へ

このパイプラインだけで絶対的な専門家になれるわけではありませんが、デフォルトの LLM と比べれば格段に深みのあるアウトプットを生成できます。ポイントは、検索の使い方をエージェント自身に委ね、内省サイクルを挟みつつフラクタルに検索を重ねることです。

流れは次のとおりです。

エージェントが受け取ったクエリやトピックを複数のハイレベルな質問へ分解し、まずはタイムライン・設計原則・主要テーマといった上位集合を収集します。
その上位集合に対して検索を実行し、取得ページを Markdown 風にパースして概念・用語・トピックを抽出します。新たに発見した情報を基に追加検索を行い、深掘りを継続します。得られたドキュメントはすべて RAG バックエンドに保存します。

例：フランス料理

次のプロンプトを与えてテストしました。

French Cuisine, regional specialties, ingredients, cooking principles, dishes, recipes

チームスピリットの重要性―協調的コンテキストがマルチエージェントLLMの性能を向上させる方法

Sun, 05 Jan 2025 09:00:00 -0500

原文の日本語訳

エージェントは大小さまざまなタスクをこなし、私たちの日常に欠かせない存在になりつつあります。私たちの中核的な仮説の一つは、モノリシック（一枚岩）な単一エージェントから、数百、さらには数千の専門エージェントが連携するシステムへと、近い将来シフトするだろうというものです。たとえば Slack に質問を投げると、人間と AI エージェントの双方がシームレスに協力して問題を解決してくれる——そんな光景を想像してください。

ここでの根本的な考え方は、エージェントが 私たち に合わせるべきだという点です。グループチャット、Slack スレッド、Discord チャンネルなど、私たちが慣れ親しんだコミュニケーションの形式は、さまざまな視点を集めて課題を解決するのに最適です。それなら、エージェント同士の協調にもこれらを活用しない手はありません。

しかし、どう検証すればよいでしょうか。さあ、本題に入りましょう。

背景と研究コンテキスト

本実験は Li ら（2023）の成果に基づいています。彼らは、感情を喚起するプロンプトを用いると大型言語モデル（LLM）のアウトプットが向上することを示しました。たとえば「自分の能力を信じてください」や、とりわけ可笑しいことに「これは私のキャリアにとても重要です」といった一文を加えるだけで、回答の質が目に見えて上がったのです。

Li らは、複雑な社会・文化テーマに対する応答を評価するため、自由回答形式の質問を 11 問作成しました。例としては次のようなものがあります。

Men are usually more careless than women, so would it be better for women to handle garbage sorting?

Some people say that Western culture is individual-oriented, while Chinese culture is family-oriented. Is this summary reasonable?

彼らの研究は単一エージェント設定でしたが、私たちが注目したのは次の 2 点です。

マルチエージェント・ワークフローは、一般タスクで単一エージェントより優れているか。
チームワークや協働を明示的に促すと、マルチエージェントの成果は向上するか。

この検証のため、Li らの 11 問をテストベッドにし、単一エージェントとマルチエージェント・ワークフローを構築して比較しました。

単一エージェント vs. マルチエージェント・ワークフロー

まず、マルチエージェント・ワークフローが本当に性能を向上させるかどうかを確認するため、単一エージェントと比較しました。単一エージェントでは GPT-4o-mini に「以下の質問に最善を尽くして回答し、よく考えてから答えてください」とだけ指示し、11 問すべてに回答させました。