LLMやAIエージェントをソフトウェアに組み込むプラクティス

Developers Summit 2026 Summer 『LLMやAIエージェントをソフトウェアに組み込むプラクティス』登壇資料
https://event.shoeisha.jp/devsumi/20260716/session/6864

Transcript

1. LLMやAIエージェントを ソフトウェアに組み込む プラクティス 2026/07/16 Yusuke Shibui
2. 自己紹介 shibui yusuke • いろいろ→Stability AI→LayerX→Snowflake • Senior AI/ML Architect / Field CTO • MLOpsコミュニティ運営 • 本日の登壇内容は私個人の意見であり、 所属企業を代表するものではありません。 • Github: @shibuiwilliam • FB: yusuke.shibui • X: cv_usk 猫のようで サイズは犬 猫耳メガネ LLMに聞いてみた
3. 翔泳社刊 新作『LLM・AIエージェントシステムベストプラクティス』 2026年8月20日発売予定！　　 ↓amazon.co.jp↓ 以下過去の著作も発売中！
4. 今日話すこと • コーディングエージェント時代におけるソフトウェア開発方法 • LLMやAIエージェントをソフトウェアに組み込むプラクティス • コーディングエージェントがLLMやAIエージェントをソフトウェアに組み込む • そのために信頼をエンジニアリングする方法
5. 今の変化に対する新しいメソドロジーを 提唱するのは同時代人の特権である
6. デザインパターンやマイクロサービスアーキテク チャのようなベストプラクティスがソフトウェア開発 の指針となってきたが、コーディングエージェント によるLLMソフトウェア開発でも同様の「共通指 針」は必要か？ • 方法論やプラクティスの役割 • LLMのための方法論 • 方法論をどう作っていくか LLM時代のSOLID原則は必要か？ コーディングエージェントで開発する LLMソフトウェアのSOLID原則？ 単一責務 1プロンプト1責務 開放閉鎖 モデル変化に開き、契約に閉じる リスコフ 代替可能性＝eval契約が緑か I/F分離 ツール面を最小権限に 依存性逆転 eval という契約に依存
7. 方法論はコミュニケーションツールである この要件は、あるオブジェクトや関数 が依存するオブジェクトや関数を受け 取るように実装することで結合度を下 げてコンポーネント化を促進するよう に作って。 ふえぇぇ・・・ この要件はDIパターンで作って。 了解！
8. 方法論はコミュニケーションツールである この要件はDIパターンで作って。 了解！
9. 新しい技術には名前や共通認識がない このAIエージェントはプロンプトに役 割とFew shotを書いてコンテキスト を記録してハイブリッド検索して Eval firstにして構造的にサブエージェント を使って・・・ Compaction…
10. 新しい技術には名前や共通認識がない テックリード PM このエージェン トを作って は〜い プロンプト このチケットを読んで 実装せよ • コーディングエージェントのおかげで、メ ンバーに相応規模の機能開発を依頼し ても「開発できる」ようになった。 • しかし共通認識となる LLMやAIエージェ ントをソフトウェアに組み込む実装方針や アーキテクチャが不在だと、それぞれが 独自に実装し、メンタルモデルの異なる 一貫性のないコード（メンテナビリティが 低い）が高い品質で生産される。 • 共通認識の不在は運用負債となる。
11. LLM/AIエージェントを活用するプラクティス LLM呼び出しは構造化出力で スキーマ駆動に作って。 了解！ LLM呼び出しは構造化出力で スキーマ駆動に作って。 AGENT.mdはこれ。 了解！
12. 方法論の方法論
13. 今発生していること
14. 楽しい自動開発 SOLID原則 デ ザ イ ン シ ス テ ム Modular Monolith Scrum TDD CI/CD きれいな エージェント 高度な分析 高速開発 セキュリティホール 無制限なトークン利用 重複 シャドウAI 低品質なコード
15. コーディングエージェント時代の エンジニアの重要な仕事の一つは 誰もが信頼できるソフトウェアを作る仕組みを エンジニアリングすること
16. 方法論と要件 実装 要件、仕様 方法論 機能 設計
17. AIをソフトウェアに組み込む共通認識 リ ファ ク タ リ ン グ Modular Monolith Scrum TDD CI/CD Agentic Application 要件、仕様 方法論 ？？？
18. ふたつの不透明性 SOLID原則 デ ザ イ ン シ ス テ ム Modular Monolith Scrum TDD CI/CD E v a l 1. LLM/AIエージェントをソフトウェアに組み込む方法論 2. コーディングエージェントに作られた具体的な実装と設計 機能はEvalで検証できる 非機能や設計やコストはブラックボックスになる .
19. 便利 ＞ 制御 それぞれが独自にブラックボックスを生み出しているとも言える .
20. 作り方の作り方を作る SOLID原則 デ ザ イ ン シ ス テ ム Modular Monolith Scrum TDD CI/CD AGENT.md Harness Eval Loop 制御のために利便性を犠牲にせずに信頼を作るのはエンジニアリングの醍醐味
21. 作り方の作り方を作る SOLID原則 デ ザ イ ン シ ス テ ム Modular Monolith Scrum TDD CI/CD AGENT.md ここを信頼して作るために こ こ を 設 計 す る Harness Eval Loop
22. 不確実性に対処する鉄則は、不確実な要素を 局所化して制限し、評価すること SOLID原則 デ ザ イ ン シ ス テ ム Modular Monolith Scrum TDD CI/CD 機能実装 1. 確率の封じ込め：LLM利用は指定したモジュールのみ許可し、ルールベースで制 約。入出力はスキーマ、ビルダー、ゲートウェイで管理。 2. 最小エージェンシーの原則：課題解決に対する LLM/AIエージェントの役割は最小 化するほど良い。 （最小）ルールベース →LLM→DAG→エージェント→マルチエージェント 3. 決定論ファースト、LLMロングテール：エントリーポイントは決定論的に解き、余剰 となる複雑性をLLMで対処。 a. プロトタイピングの逆転： LLMで対処した記録を元に、決定論的に解ける 領域を広げていく。 b. LLM実行で素早く失敗領域を計測しつつ、人間が変化を管理しハーネス 化。 Eval
23. 決定論ファースト、LLMロングテール 主な 商品の 推薦 ルール ベース 当初は意味的な推薦を LLMでカバー ログとともに徐々にML移行 LLM推薦は実験・エッジケースへ 稀な商品の 推薦 主な 商品の 推薦 ルールベース & 機械学習 少量商品 推薦 ユーザログか ら傾向の ある商品を ML推薦化 殆どの商品の推薦 ルールベース & 機械学習 実験 推薦 新規・実験的 エッジケース のみLLM推 薦 当初は稀な商品の推薦（≒ログではなく意味的な側面が重要）は LLMで推薦 徐々に商品ーユーザログの傾向からルールベースと機械学習に寄せていき、 LLM推薦は新規・エッジケースに移行 LLMは決定論でカバーできない領域を補助する役割を徹底
24. 「LoopしながらHarnessを作る」手順を作る AGENT.md Harness Eval Master Harness Harness Eval Looped Harness Engineering（Compound Engineering） 「各作業が後続の作業を容易にする」ように開発する。 チームでLoopしながら実装とEvalを通してHarnessを育てる。 Master Harnessをチーム共通のソフトウェア資産として、チーム（コー ディングエージェント含む）その開発者兼ユーザとなる。 • 計測する：Evalとテレメトリ（CI/CD）を設計し、Harnessの育成を 評価する。 • 枝刈りする：コンテキストや Harness、EvalをLint、評価し、積極 的に非AIの決定論に寄せていく（ CI/CD等）。LLMが読み込むの は「決定化できない残滓」。 • 統治する：HarnessやEvalはGit管理しレビューと回帰テストを通 す。 決定論的 ルール
25. 変更の信頼性をエンジニアリングする AGENT.md Harness Eval Master Harness 決定論的 ルール リリース テスト • 頻度 • リードタイム • 変更失敗率 • 実行vs枝刈り数 • 人間レビュー数 • レビュー指摘数 • 可逆vs不可逆領域 • 意思決定の移譲量 • 経済的スループット Harnessの目標関数は信頼可能な変更量 • 人間のレビューが最も高コスト • 次にLLMを含めた全件テスト • レビュー指摘数を減らすために リリースの頻度と失敗率を最適化対象 として、ハーネスとEvalをLoopして改善 していく。 • ハーネスに設計・開発可能な領域を移 譲していくことで、コーディングエージェ ントの生産量を増やし、スループットを 最大化する。 • 目標関数に対して過程を自動最適化す るのがLoop Engineering。
26. 便利 ← 制御 Harness Eval Master Harness
27. LLMやAIエージェントを ソフトウェアに組み込む技術
28. コーディングエージェントでLLMソフトウェアを開発する リ ファ ク タ リ ン グ Modular Monolith Scrum TDD CI/CD Agentic Application
29. コーディングエージェントでLLMソフトウェアを開発する Agentic Application Interface Eval Context/ Memory Tool/ Gateway
30. コーディングエージェントでLLMソフトウェアを開発する Agentic Application Interface Eval Context/ Memory Tool/ Gateway インターフェイス 外部サービス連携 テスト・CI データ・永続化層
31. 構造化出力とスキーマ駆動I/O 主な手法 LLMの出力をPydantic / JSON Schema で定義した型に強制し、自然言語では なく検証可能な構造化データとして受け取る。 LLMを「会話するモデル」から、型 付きインターフェースを持つソフトウェア部品へと変える。 解決する課題 自然言語出力のパースは壊れやすく後続処理が安定しない。スキーマ検 証で曖昧さ・パースエラー・予期せぬ形式を排除し、自動処理を可能にす る。 アーキテクチャ LLM (Schema指定) 検証 (Pydantic) 型付き オブジェクト 検証失敗 → 再生成 重要性と懸念点 重要性　パイプライン・ツール連携・評価・ログのすべての土台。 これなしに本番の安定はない。 懸念点　スキーマが複雑すぎると生成失敗率が上がる。検証失 敗時の再試行とフォールバック設計が必須。 LLM/AIエージェントをソフトウェアに組み込むプラクティス
32. コーディングエージェントが実践するためのプラクティス 「構造化出力とスキーマ駆動I/O」の作り方 主な手法 解決する課題 LLMを使うソフトウェアをコーディングエージェントで開発するとき、要件や 仕様に応じてコーディングエージェントが適した構造化出力のスキーマを 定義できるように、定義方法や選択可能な型、ルールを AGENT.mdにす る。 重要性と懸念点 重要性　構造化出力をコーディングエージェントで自動開発する 適合性を担保する。 懸念点　LLM（OpenAI, Claude, Gemini）によって構造化出力 の仕様が微妙に違っており、共通化が難しい。 課題 LLM 期待する 構造スキーマ ＝ 課題に応じて構造化出力の スキーマを定義するLLMの 定義ルールを文書化
33. 「構造化出力とスキーマ駆動I/O」のハーネス 原理 • 決定/確率国境：LLM->構造化出力は確率的世界から決定論への ボーダーであり、Evalを必須とする。 • 4組契約原理：Schema x Prompt x Model x Evalで契約単位とす る。 • 読者転換：スキーマの第一読者は人間ではなくLLM。 スキーマ設計 • 2重モデル：LLMのスキーマとドメインモデルを分け、変換層を持 つ。 • 説明とPromptの分離：説明や意味、Promptは手順。 • 自然言語は制約する：Enum/Literal。Strは可能な限り長短や法則 を指定する。 • 不明の表明：抽出系フィールドはOptionalとして、不在時の Hallucinationを防ぐ。 • 根拠の表明：抽出系フィールドは根拠を原文で取得する。 • 思考から生成へ：Reasoningフィールドを優先し、結論は最後にす る。 • スキーマ複雑性の削減：Nestは上限3とし、専門性に応じて積極的 に分割する。 検証 • 型チェック→Domain Model validation→現行業務照合。 • Pydanticが評価するのは型チェックまで。ドメインと現行業務は常 に追加実装が必要。 失敗のデザイン • 呼び出し側に失敗分岐の型を矯正する。 • Criticalityを階層的に評価する。補助代替可能→劣化Fallback許 容→Human-in-the-loop必達。 • エラーメッセージは「What, Why」と「How to fix」を出力する。 契約 • スキーマをバージョニングし、レスポンスのトレースにはバージョン を含めて記録する。 • 4組契約（Schema x Prompt x Model x Eval）とともにログ。 • 可能ならスキーマレジストリでルール定義を強制。 コーディングエージェントを制御するハーネス（抜粋）
34. コンテキストとメモリ設計 主な手法 エージェントが長時間で蓄積する文脈を設計対象として扱う。健全な状態をチェッ クポイントに保存し、汚染・ドリフトを検知したらロールバックして不要な過去を忘 れ、有効な入力だけ再送する。共有メモリは排他制御で更新する。 長い対話や自律ループは文脈が意味的に汚染され、初期の幻覚が全体 へ伝播する。並行エージェントは共有状態が競合しデータが壊れる（ lost update）。 アーキテクチャ 重要性　エージェントを長時間・安定して走らせ、暴走や崩壊から 確実に回復させる中核。 懸念点　忘却の粒度とタイミングの設計が難しい。必要な情報ま で捨てる／排他制御でスループットが落ちるトレードオフ。 解決する課題 重要性と懸念点 文脈の蓄積 汚染・ドリフト 検知 健全な地点へ 復帰 不要な過去を忘却 → 有効入力を再送 LLM/AIエージェントをソフトウェアに組み込むプラクティス
35. 「コンテキストとメモリ設計」のデータデザインカタログ 主な手法 LLMで扱える有用なデータは多様である。データの形態や用途によって 適した保存・管理・検索・取得方法は異なる。各データソースのメタデータ をデータカタログで管理しつつ、そのデータとデータカタログの作り方や技 術選定方法を「データデザインカタログ」として文書化。 重要性　データの用途や形態に応じたデータ設計をデータ設計 デザインに応じて選定し、適したデータ構造と基盤を実現する。 懸念点　データの規模や複雑性によっては Too muchなエンジニ アリングになる。データは半永久的に管理が発生するため、「不 要」と判断する基準も必要。 解決する課題 重要性と懸念点 データ カタログ データ デザイン カタログ コーディングエージェントが実践するためのプラクティス データの形態や用途に応 じたデータシステムの設 計方法を指示
36. 「コンテキストとメモリ設計」のハーネス（抜粋） 原理 • 認証認可と予算：コンテキストの記録参照はAuthとトークン理由が 必要。 • 出自と帰属：すべてのメモリには出自と帰属があり、出自や帰属が 変更されたら子はすべて追従するか無効化する。 • カタログ：記録されうるデータはすべてカタログに登録され、スキー マ、所有、鮮度、アクセス制御、検索が管理される。 データデザインカタログ（設計） • 全ソース登録制：カタログにないコンテキストはビルドされない。生 データ、継承データともに出自を含めて記録される。 • 項目：所有、スキーマ、保存形式、ライフサイクル、アクセス制御、検 索契約、コスト。 • 用途別ストア選定：データ性質が保存形式と検索手段を決める。事 実・設定値は構造化データ（KVS/RDB）、出来事はイベントログ、知 識はチャンクとハイブリッド検索インデックス、手順は検索とGit。 • 検索契約：各ソースは型付き検索を公開する。 • メタデータ付きメモリ：メモリレコードは本文とメタデータがセットとな る。 データデザインカタログ（記録とLineage） • 書き込みは審査制：メモリへの書き込みはEvalが必要。 • 検疫と昇格：記録は検疫を通して承認され、利用を通して昇格する。 • 観測と推論の分離：「今日は晴れ」（観測）と「彼は寿司が好きらしい」（推 論）は分離して管理する。 • Immutable：メモリは常にイベントソーシング。矛盾やスキーマ変更を含 めて記録してトレース。 データデザインカタログ（読み出しと組み立て） • 生データとビュー：破壊的圧縮の禁止。ログを原文とし、要約は Materialized Viewとする。 • ビルダー：コンテキストはビルダーを通して決定論的に組み立てて利用。 • 前方安定・後方可変：規範やスキーマ→検索結果や履歴の順に組み立て る。 • 無関係はゼロに劣る：検索関連度で弱関連は棄却する。 データデザインカタログ（ライフサイクル） • TTLに上限を設ける：全レコードにTTLと減衰率を宣言。 • 忘却は機能：定期的にGCしてメモリを有効性と有用性で評価する。 コーディングエージェントを制御するハーネス（抜粋）
37. ツールチェーンとゲートウェイ 主な手法 Function calling/Tool callやMCPによってLLMから外部システムを活用する仕 組み。 発展系として、LLMは呼び出す関数の連鎖と順序だけを指定し、システムが内部 で一括実行して最終結果（ ID参照）のみを返す。全ツール呼び出しはゲートウェイ （MCP）を制御点に、認可・スキーマ検証・最小権限・監査を一元化し、多数のツー ルは動的に発見・選択する。 逐次のツール往復は中間結果で文脈を汚し、トークンとレイテンシを浪費 する。ツールが増えると認可・監査・選択が破綻し、任意実行のリスクも 高まる。 アーキテクチャ 重要性　大量ツール・多段処理を、低コスト・型安全・統制の効い た形で実運用する応用基盤。 懸念点　チェーンの事前検証（ドライラン）とツール契約の設計が 必須。ゲートウェイが単一障害点・ボトルネックになりうる。 解決する課題 重要性と懸念点 LLM (連鎖を指定) ゲートウェイ 認可・検証 ツール連鎖 ①→②→③ 最終結果のみ ID参照で返却 LLM/AIエージェントをソフトウェアに組み込むプラクティス
38. 「ツールチェーンとゲートウェイ」のフレームワーク化 主な手法 ツールチェーンは関数をチェーン実行する単位を管理するためのプロン プトとセットで開発することになる。関数群とプロンプトの両方を同期的に 管理する必要があるため、セット管理のためのフレームワークを用意し て、フレームワーク側をコーディングエージェントが参照する仕組みが必 要。 重要性　複雑なルールベース処理を多様なツールチェーンで実 践するためのハーネスとなるフレームワーク。 懸念点　複雑性が増すと同時に、フレームワークの更新に対して コーディングエージェントがリファクタリングする仕組み（ SKILL）が 必要。 解決する課題 重要性と懸念点 プロンプト ツールチェーンと そのプロンプトを セットで開発 セットのフレームワーク化 コーディングエージェントが実践するためのプラクティス
39. 「ツールチェーンとゲートウェイ」のハーネス 原理 • プレーン分離：LLMは目標と順番を決め、それ以外はデータプレー ンが持つ。中間生成物はLLMを経由しない。 • 因果の非対称性：読み書きは非対称。ツールは副作用を持つ。 • 5組契約：ツールセット x チェーン仕様 x プロンプト x モデル x Eval。 • 事前検閲：プランは事前にコンパイルして型検査や権限精査を通 す。必要に応じてリスクとコスト検査。 ツール設計 • 能力指向：ツールはタスク形状で特定スキル指向。 • What/When-to-use/When-NOT-to-use：それぞれを例示。 • 引数：Enum優先、名前ではなくID、「汎用引数」禁止。フィールドごと にリスク評価を仕組みで組み込む。 • 宣言的副作用クラス：各ツールにRead/Write-reversible/ Write-irreversible/External-sendを必須宣言。 • 返り値ID：巨大なレスポンスはコンテキストに記録し、IDをLLMに渡 して参照値とする。 チェーン設計 • 型付きプラン：プランは構造化された宣言的DAG。 • 参照束縛：実行時評価で参照IDを解決。 • 補償 or チェックポイント：不可逆処理は補償アクションかチェックポ イントとともに実装。 • 読みは対話許可、書きは宣言的：Read-onlyであればLLMによる 対話を許可するが、書きでは常に宣言的プランを強制。 ゲートウェイ • Single Tool Gateway：ツール直呼び出しをLintで禁止し、ツール利 用は常にゲートウェイを通す。 • 実行台帳：ゲートウェイでツールチェーン実行を管理記録。 レジストリとフレームワーク • カタログ登録されるツールレジストリ：ツールはデータカタログの1カ テゴリとして登録し管理。検索含む。 • プラン時検索：プラン時に必要なツールを検索、発見、選定。 • フレームワーク：ここまでのルールをフレームワークとして強制。フ レームワーク自体が自己記述（Agent.md）を自己認識し、実態とレ スポンスを一致させる。 コーディングエージェントを制御するハーネス（抜粋）
40. AIエージェントのテストと評価 主な手法 品質を勘ではなく数値で管理する。ゴールデンデータセットに対し、ルーブリックや LLMによる自動採点でオフライン評価を自動化し、合否閾値を CIの品質ゲートに 組み込む。本番ではカナリアと A/Bで実挙動を測り、トレースを継続的にデータセッ トへ還元する（Eval駆動開発）。 出力は値でなく分布のため、単体テストの 1例合格では品質を保証できな い。評価がなければ劣化・回帰・幻覚に誰も気づけず、モデルやプロンプ トの変更を安全にリリースできない。 アーキテクチャ 重要性　変更を安全に出荷するための唯一の測定基盤。プロン プト・モデル・ツールの改善を回帰なく継続できる。 懸念点　評価器（特にLLM-as-Judge）自体のバイアスと不安定 さ。データセットの陳腐化・リークと評価コストの増大に注意。 解決する課題 重要性と懸念点 オフライン評価 Golden×Judge CI品質ゲート 合否閾値 オンライン評価 カナリア/A・B 本番トレース → データセットへ還元 LLM/AIエージェントをソフトウェアに組み込むプラクティス
41. 「AIエージェントのテストと評価」の最適選定 主な手法 LLM/AIエージェントのテストはコストが高く遅い。少しの変更に対して全 件テストするのではなく、変更箇所から確率的に失敗しそうなテストを選 定して優先的にテスト実行する。また、失敗したテストに対して関連性の 高いテストを次に評価する。 Predictive Test Selectionを応用する。 重要性　LLMでは網羅的なテストが望ましい一方、全件実行は 経済的に非合理。過去のテスト実行やコード／プロンプトの関係 から優先順位をつけて選定。 懸念点　確率的であるため、ヌケモレが発生するリスク。本番リ リース前は全件実行して、それ以外では Test Selectionを活用。 解決する課題 重要性と懸念点 変更 テスト 変更に対して確率的に失敗しそ うなテストを優先的に実行する。 失敗したテストに関連性の高い テストを選定。 コーディングエージェントが実践するためのプラクティス
42. 「AIエージェントのテストと評価」のハーネス 原理 • 推定原理：標本数・信頼区間・検出力を統計的に評価する。 • 予算原理：単位コストあたりの回帰検出期待値を最大化。何を実行 し、実行しないかを目指す。 • 系譜原理：変更の系譜から実行するテスト・追加するテストを導く。 • 計器校正原理：テスト測定機が劣化すると想定する。 変更モデリング • 変更＝マニフェスト：リリース候補は型付き変更マニフェストで記述。 変更は機械可読を補償。 • 変更種別と戦略：プロンプト変更、スキーマ変更、コード変更、環境 変更それぞれに対して有効なテストの強制と選択を設計。 • ゼロ変更≠ゼロリスク：全件実行をCRONで定点観測し、ブラックボッ クスなドリフトを検出。 予算 • 予算検証：変更に対するテスト予算を記録し推論、最適化。 • 未検証ノート：省略したテストを記録し、検証できていない事項をレ ビュー対象とする。 予測選択 • 予測対象は増分：Fall | Changeを差し引いたUpliftを予測。 • 特徴量は系譜・意味・履歴：変更の系譜と意味をテスト履歴と紐づ ける。 • 安全閾値：ベースラインとして常に実行するテストを選定。 カスケード診断 • 失敗は接触追跡：失敗したEvalの系譜を記録し、失敗半径を分析 可能化。 • 失敗の型分類：失敗原因を分類してルールベースでテスト選定でき ることを目指す。 統計と測定 • 判定関数の型宣言：Evalは決定論的・閾値付き統計・LLM Judge、 人間のいずれかを宣言。 • 逐次検定：重要度に応じて標本数を設定しつつ、因果からEarly Stopping可能な領域を定義。 • LLM Judge免許制：Judgeは評価対象として免許制とする。免許さ れたJudgeはロックする。Judge Driftを防ぐ。 コーディングエージェントを制御するハーネス（抜粋）
43. 【アンチパターン】神プロンプト アンチパターン LLMを万能の黒箱とみなし、巨大な自由形式プロンプトを 1回投げて、返ってきた 自然言語をそのまま信じる。スキーマも分割もツールも評価もない。 • 言い回しが変わった日にパースが壊れる • 品質劣化に誰も気づかない（評価なし） • 自信満々の誤計算と古い事実 • どの工程で失敗したか特定不能 • プロンプトインジェクションに無防備 崩れる構造 違反　構造化出力、多段分割、 Tool委譲、Eval-Centric AI 処方　スキーマで型を強制 → 検証可能な多段に分割 → 厳密 処理はツールへ委譲 → 提供前に自動品質ゲート 症状 違反と処方箋 ユーザー 自由入力 巨大プロンプト （全部入り） 自然言語出力 → 手パース 欠落 ×：スキーマ ／ 分割 ／ ツール ／ 評価
44. 【アンチパターン】Local LLM Function アンチパターン API呼び出しを必ず即時成功し、無料でログ不要で状態を持たないローカル関数 のように扱う。エージェントを無制限にループさせ、文脈を無限に伸ばす。 • プロバイダ遅延が即「全断」に連鎖 • コスト爆発とレート制限の嵐 • エージェント暴走でコスト消失・ハング • 長時間会話が腐る（ドリフト・競合） • ログがなく障害をデバッグ不能 崩れる構造 違反　TO/Retry/FB、流量・優先・GW、構造化ログ、ガードレー ル、メモリ 処方　LLM clientは共通化、GWで流量・優先制御、ログ記録、 キャッシュ・バッチ、エージェントは反復 /コスト上限で境界設計 症状 違反と処方箋 アプリ LLM API （直結） × Timeout/Retry × Cache × Log × Rate制御 エージェントループ → コスト爆発・ハング
45. 非機能の落とし穴 1 決定論バイアス 品質・テスト軸 「テストが通った＝正しい」「バージョン固定で挙動は不変」——熟練の直感を 適用する。だがLLM出力は値でなく“分布”で、1例の合格は何も保証しない。 本番での症状 • デモでは動くが本番で再現不能 • プロンプト改変で品質が劣化 • 緑のCIが誤った安心を与える 処方　例でなく“分布”を検証。N回サンプリング＋基準付き自動判定で ゲート＋CI回帰。 2 信頼境界の取り違え セキュリティ軸 ユーザー入力は警戒する一方、LLMの出力（生成SQL/コード・ツール引数） とTool/RAG内容を“自コード”のように信頼する。境界が人間の位置のまま LLMが内側に入る。 本番での症状 • 生成コードの無検証実行でSQLi/SSRF • RAG/ツール出力の注入で操作される • 破壊的ツールが承認なしで実行 処方　信頼境界をLLMの外側へ。非信頼として検証・サンドボックス・ 最小権限・人間承認。 共通構造　熟練の反射が、技術が壊した新しい前提と衝突する。新パターンの習得（足し算）だけでなく、旧反射の棄却・再較正（引き算）が要る。
46. コーディングエージェントのための方法論 Harness Eval 設計指針 選定基準 Harness Eval Harness Eval Harness Eval Harness Eval AGENT.md 検索
47. 変化とメソドロジー 技術が壊す「当たり前」から メソドロジーが生まれる 新技術 「当たり前」 が壊れる 失敗が 集中する 局所化して 評価する メソドロジーが 生まれる 次の変化が新しい前線を開く 今の変化に対する新しいメソドロジーを 提唱するのは同時代人の特権である。
48. LLMやAIエージェントを ソフトウェアに組み込む プラクティス ありがとうございました！