Google Antigravity を使い込んでいると、だんだんと見えてくることがあります。「このエージェントは、なぜこういう挙動をするのだろう」という疑問の多くは、結局のところ『情報の重みづけ』『候補の絞り込み』『推論の確率分布』といった、古典的な情報科学の問題に行き着くのです。
この視点は、最近読んだ数学書（古嶋十潤『独学で鍛える数理思考』）からヒントを得ました。同書ではGoogle検索のTF-IDFから始まり、レコメンド、画像分類、生成AIまでを連続したカリキュラムとして数理的に解き明かしていきます。AIエージェント設計も、表面的な「指示の書き方」ではなく、こうした数理的構造の理解に立ち戻ったほうが、結果的にずっと安定したエージェントを作れることに気づきました。
ここではAntigravity の Architect / Builder の二段構成を題材に、エージェント設計を数理的思考のレンズで整理し直します。
Architect / Builder は『情報の絞り込み問題』として捉えられる
Antigravity の Architect は要件定義と設計、Builder は実装を担当する二段構成です。これを単に「役割分担」と捉えるのではなく、『情報の絞り込みパイプライン』として見ると一気に見通しが良くなります。
ユーザーから来る要望は通常、ふわっとした自然言語です。「ログイン機能を実装したい」のような曖昧な要望に対して、Architect は『考えられる実装パターンの空間』から具体的な設計仕様へと絞り込みます。Builder は、その仕様から『可能なコードの空間』へと再度絞り込みを行います。
これは数学的には、徐々に解空間を狭めていく『候補削減アルゴリズム』に似た構造です。検索エンジンが100億ページから10件のページを選ぶプロセスと、本質的には同じことをしています。違うのはランキング関数が TF-IDF や PageRank ではなく、Geminiモデルの推論である点だけ。
この視点が役に立つのは、Architect の出力が変だなと感じたときに『情報の絞り込みのどこで失敗したか』を切り分けられるようになるからです。要件が抽象的すぎて空間が広すぎるのか、コンテキストが少なすぎてランキング関数が正しく働かないのか。これを意識すると、プロンプト改善の方向性が明確になります。
TF-IDFから学ぶ『コンテキスト設計』の本質
TF-IDF（Term Frequency–Inverse Document Frequency）は、検索エンジンで使われる古典的な単語重要度モデルです。「ある文書によく出てくる単語ほど重要、ただしどの文書にも共通して出る単語は重要度が下がる」というシンプルな考え方です。
このモデルから AIエージェント設計に持ち込める教訓が2つあります。
ひとつは『繰り返しの強調が逆効果になる』こと。あなたが Architect への指示で「絶対に〜してください」「必ず〜です」と何度も繰り返すと、その単語が文書全体に頻出する状況になり、TF-IDF的に重要度が下がります。同じことを言い換えるよりも、本当に重要な制約を1〜2回だけ明示するほうが、エージェントの注意を集中できます。
もうひとつは『珍しい単語が情報量を持つ』こと。「我々のシステムでは zoning constraint を必ず満たす必要がある」のように、その文脈固有の専門用語を使うと、エージェントはその用語に強く反応します。逆に「ちゃんと」「うまく」「適切に」のような汎用語は、IDF的にほぼ情報量がないため、エージェントには伝わりません。
私が Architect への指示を書くときの個人的なルールは、「曖昧な日本語1文よりも、具体的な専門用語1個」です。これは TF-IDF的な情報量設計の発想を、自然言語のプロンプトに持ち込んだものです。
分類問題から学ぶ『エラーケースの設計』
機械学習の分類問題では、『正例（陽性）』と『負例（陰性）』のバランスが性能を大きく左右します。負例を十分に与えないと、モデルは『すべてを正例だと判断する』偏った分類器になります。
これは AIエージェントの指示でも全く同じことが起きます。「〜してください」だけを書いていると、エージェントは何でも『指示通りやる方向』に判断を寄せます。失敗ケースや禁止事項を一切示さないと、エージェントは『境界を知らない』状態に陥り、想定外の挙動を取りやすくなります。
具体例で言うと、私が Antigravity の Architect に対して書く指示には、必ず以下の構造を入れています。
- 何をすべきか（正例）
- どういう成果物が望ましいか（正例の詳細化）
- どういう判断は禁止か（負例）
- どこまで自分で決めて良いか（境界）
特に『負例』と『境界』の指定が、エージェントの暴走を防ぐ最大の安全装置です。これも数学的には『分類問題における決定境界の明示化』であり、機械学習の基礎理論がそのままプロンプト設計に応用できる例です。
推論モデルから学ぶ『不確実性の取り扱い』
近代的な確率モデルでは、『分布全体』を扱うことが重要視されます。点推定（最も確率の高い値1点）だけを使うと、モデルがどれだけ自信を持っているかの情報が失われます。
AIエージェントへの指示でも、同じ発想が効きます。「最善の解を1つ示してください」と頼むと、エージェントは1つの解だけを返してきますが、その解にどれだけ自信があるかは見えません。代わりに「上位3案と、それぞれのトレードオフを示してください」と頼むと、解空間の分布が見えるようになり、人間側で判断する余地が生まれます。
私が Architect に新機能の設計を頼むときのテンプレートはこんな感じです。
要件: ユーザーがログインできるようにしたい
出力形式:
1. 上位3案を提示してください（OAuth/JWT/セッション等）
2. 各案について、メリット・デメリット・推定実装工数を示してください
3. 我々のスタック（Cloudflare Workers + KV）に最も適したものを推奨してください
4. 推奨案を選んだ確信度（高・中・低）と、低い場合の追加情報要求を示してください
『確信度』を明示的に求めるのが地味に効きます。エージェントは確信度が低いケースで質問を返してくるようになり、不確実性が残ったまま実装に進むことを防げます。
Builder への指示には『最適化の制約』を明示する
Architect が設計を出したあと、Builder にコード実装を任せる段階。ここで効くのが『制約付き最適化』の発想です。
数学的最適化の問題は、目的関数（最大化したいもの）と制約条件（守らなければならない条件）の組み合わせで定義されます。AIエージェントへの指示も、これに従って明確化すると Builder の出力が安定します。
目的: ログイン機能を実装する
制約:
1. 既存の handleAuth() 関数を必ず呼び出すこと
2. KV namespace の構造を変更しないこと
3. テストカバレッジ80%以上を維持すること
4. Cloudflare Workers の CPU時間 50ms以内に収まること
こう書くと、Builder は単に「動くコード」を書くのではなく、すべての制約を満たす中で『目的関数』に沿ったコードを生成します。逆に制約を曖昧にすると、Builder は最も低コストな実装（しばしば既存の構造を壊す）を選びがちです。
数理的思考が役に立つ『3つの場面』
ここまでの話を踏まえて、Antigravity でエージェントを設計するときに数理的思考が特に効く場面を3つに絞ります。
第一に、エージェントが想定外の挙動を取ったときの原因分析。 表面的に「プロンプトを変えてみる」のではなく、『情報の絞り込みのどこで失敗したか』『負例が足りていないか』『確信度を求めていないか』といった構造的な問いを立てると、再現性のある改善ができます。
第二に、複数エージェントを連携させる設計。 Architect → Builder のような二段構成だけでなく、レビュアー、テスト生成者、デバッガなど多段化が必要になったとき、各段の入出力を『情報空間の絞り込み』として定義すると、責任範囲が明確になります。
第三に、エージェント評価の設計。 「うまく動くか」を主観で判断するのではなく、評価データセットに対する『正解率』『F値』『再現率』といった分類問題的な指標で測ると、改善が定量的に進められます。
締めくくり：数学は『言語』である
数理的思考というと身構えてしまいがちですが、本質はシンプルです。それは、曖昧な現象に対して『これは構造的にどういう問題なのか』と問いを立てる思考の言語を持つことです。
私自身、AIエージェント設計に数学的視点を持ち込んでから、プロンプトの改善が試行錯誤ベースから理論ベースへと変わってきました。「とりあえずプロンプトを変える」ではなく「TF-IDF的に重要度が下がっている単語があるからこれを削る」のように、改善方針を言語化できるようになります。
次の一歩としておすすめなのは、自分が普段書いている Architect への指示を1つ取り出して、『情報の絞り込み』『正例と負例』『制約付き最適化』の3つのレンズで読み直してみることです。きっと改善ポイントが見つかります。それが、エージェント設計を数理的に考える出発点になります。