🏗️ 一時的なコードから持続可能な設計へ

エージェント型AI時代におけるモデリングの隠れた価値

誤解: 「AIは今、コードを書けるので、アーキテクチャは重要ではない。」
現実: 「AIは今、行動を実行しているので、アーキテクチャの重要性はかつてないほど高まっている。」

🚨 警鐘の発射

我々は、次のような金鉱ブームを目撃している:使い捨てコード開発者はテープで固定したプロンプトでAPI呼び出しをつなぎ合わせており、デモでは完璧に機能するが、本番環境では崩壊する脆い論理の連鎖を構築している。

チャットボットの時代には、幻覚は面白いエラーメッセージだった。
エージェント型AIの時代には、エージェント型AI幻覚は、削除されたデータベース、承認されていない送金、またはコンプライアンス違反である。

生成型AI（テキストの生成）から生成型AI（テキストの生成）へ移行する中で、エージェント型AI（タスクの実行）へ移行する中で、ソフトウェアモデリングの価値は低下しているのではなく、急上昇している。これは、未来は最も優れたプロンプト作成者ではなく、最も優れたモデラーに属する理由を語る物語である。

📉 「プロンプト最優先」アーキテクチャの罠

現在、多くのチームは次のようにエージェントを構築している:

入力:ユーザーが複雑な要求をする。
処理:LLMは50のルールを含む巨大なシステムプロンプトを受け取る。
行動:LLMは直接JSONまたは関数呼び出しを出力する。
リスク:状態の追跡なし、型の安全性なし、『どうか間違わないでください』という程度のガードレールなし。

⚠️ スケーリング時になぜ失敗するのか

機能	プロンプトのみのアプローチ	モデル化されたアプローチ
信頼性	確率的（うまくいくことを願う）	決定論的（保証された制約）
デバッグ	「プロンプトがあまりに曖昧だった」	「状態遷移がルール4に違反した」
スケーラビリティ	コンテキストウィンドウが速やかに満杯になる	状態は外部化され、管理される
安全性	LLMの整合性に依存する	スキーマ検証に依存する

💡 主な洞察：モデルのないエージェントは、ルートアクセスを持つ混沌としたインターンにすぎない。モデルを持つエージェントは、チェックリストを持つシニアエンジニアである。

🧱 モデリングのルネサンス

モデリングとは、誰も読まないUML図を描くことではない。エージェント時代において、モデリングとは AIが安全に考えられるためのガードレールを作ることである。

1. ドメインモデリングを「真実の基準」として 🌍

LLMはインターネット全体で訓練されているが、それは あなたのビジネスロジックではない。エージェントに「払い戻しを処理してください」と頼むと、公開データに基づいてその意味を推測する。

解決策：厳密な ドメインモデル.
価値： あなたはLLMに、自然言語理解を自らの文脈に合わせてマッピングさせます。 あなたの 特定のエンティティ（注文、顧客、ポリシー）に。これにより、AIをあなたのスキーマに固定することで、幻覚を低減します。

2. 状態モデリングを「記憶」として 🧠

エージェントは、ワークフローの中でどこにいるかを把握する必要があります。プロンプトチェーンは文脈を失います。

解決策： 実装する 状態機械 （例：アイドル → 計画 → 実行 → 検証 → 完了）。
価値： エージェントはステップをスキップできません。「計画」する前に「実行」できません。「検証」する前に「完了」できません。

3. 制約モデリングを「安全」のためのものとして 🛡️

エージェントが使ってはいけないAPIを呼び出そうとした場合、どうなるでしょうか？

解決策： オントロジーと能力マップ。
価値： エージェントは、現在の状態に有効なツールしか認識しません。 literally できない 見ることができない delete_user 関数は、read_only_modeにいる間は read_only_mode.

🛠️ ケーススタディ：トラベルエージェントの対決

AIトラベルエージェントを構築するための2つのアプローチを見てみましょう。飛行機とホテルの予約が可能です。

❌ アプローチA：使い捨てスクリプト

ロジック： 一つの巨大なプロンプト： 「あなたは旅行エージェントです。ユーザーのためにフライトとホテルを予約してください。これらのツールを使用してください。」
失敗モード： ユーザーが「火星へのフライトを手配して」と言う。LLMは無効なパラメータでフライトAPIを呼び出そうとする。あるいは、フライト日程の確認前にホテルを予約し、衝突を引き起こす。
結果： 予約の破綻、怒った顧客、APIレート制限による禁止。

✅ アプローチB：モデル化されたシステム

論理： A ワークフローグラフ.
1. 意図状態： 目的地がデータベースに存在することを検証する。
2. フライト状態： 検索 → 選択 → 保留（在庫をロック）。
3. ホテル状態： 検索 → 選択 → 保留。
4. 取引状態： カードを請求 → 両方を確認 → 解除。
成功モード： ユーザーが「火星」と言えば、ドメインモデル LLMがAPIを見ることなく、目的地を拒否する。フライトに失敗した場合、ステートマシンはホテルの保留を自動的にロールバックする。
結果： 堅牢で、監査可能で、回復可能な取引。

🚀 経済的議論：技術的負債 vs. 設計負債

モデル化は開発を遅らせるという誤解がある。AI時代においては、むしろ逆である。

プロンプトチューニングは反復的負債である： プロンプトを調整すると、別の部分が壊れる。「Xをしないで」と追加すると、「Y」もできなくなる。これは高維持コストの負債である。
モデル化は初期投資である： タイプと状態を一度定義する。AIはモデルに適応する。ビジネスロジックが変更されたとき、50ページのシステムプロンプトを変更するのではなく、モデルを更新する。

📉 コスト曲線：

週目1: プロンプト入力は速い。

月目1: モデリングは同等の速度。

年目1: プロンプト入力は保守不能なスパゲッティコードである。モデリングは資産である。

🧭 アーキテクトの新しいツールキット（M.A.P.）

エージェント時代に生き残るためには、以下のものを採用せよM.A.P. 次のAIプロジェクトのためのフレームワーク：

1. Mデータをモデリングする

LLMに原始的な文字列を出力させない。出力を必ず Pydanticモデル または JSONスキーマ.

ルール： 型がついていなければ、それは現実ではない。

2. Aフローを設計する

LLMに処理の順序を決めさせない。代わりに ステートマシン または ワークフローエンジン （TemporalやLangGraphなど）。

ルール： LLMはスロットを埋める。コードが車を動かす。

3. P境界を保護する

定義する 事前条件 および 事後条件 エージェントが使用できるすべてのツールについて。

ルール： 信頼はするが検証せよ。実行前に常にエージェントの出力を検証すること。

🔮 未来：建築家は園芸師として

過去では、開発者はレンガ職人であり、コードの一行一行を手作業で配置していた。
未来では、開発者は 園芸師.

すべての葉を手で配置するわけではない。あなたが行うのは、トレリス（モデル）を設計し、土壌（データ）を豊かにし、危険な枝（制約）を剪定することだ。その後、AIが成長するのを許すのだ。

使い捨てコードはデモを構築する。
持続可能な設計は帝国を築く。

初期のAIブームの塵が落ち着く中、市場は最も多くのコードを生成できる者に報いるのではない。報いるのは、そのコードを正しく保つシステムを設計できる者である。そのコードを正しく保つシステムを設計できる者。

🏁 最後の教訓

コードをやめないで。モデル化を始めよ。AIはエンジンだが、しかし あなた はハンドルだ。