『LLM/AIエージェントシステムベストプラクティス』が無事発売されました！ Kindleが2つフォーマットがあると知らず、2冊買ってしまった。

新著『LLM・AIエージェントシステムベストプラクティス』の見本が届きました！ これで3冊目！ 8/20発売です！ 今回も頑張りました。

8/20に発売する自著『LLM・AIエージェントシステムベストプラクティス』について『AIの全盛期にAIの本を書く』というブログを書きました。

3冊目の自著『LLM・AIエージェントシステムベストプラクティス』を発売します！ 発売日は8/20です！ 内容はここ数年いろいろ試してきたLLMをソフトウェアに組み込む方法やAIエージェントのアーキテクチャ、その他LLM関連のエンジニアリングを設計検証したプラクティス集です。 サンプルコードも一緒に公開します。 ご興味ある方はぜひご一読いただけると幸いです！ #LLM# #技術書#

本日19:30より @Forkwell 様主催の #Forkwell_Library# で『LLM・AIエージェントシステムベストプラクティス』について登壇します。 資料はこちらです。 よろしくお願いします。

ありがたいことに、8月は以下の勉強会・イベントで登壇させていただきます。 8/11（火）MLOps/LLMOps/AgentOps勉強会 8/31（月）BPStudy#228〜LLM・AIエージェントシステムベストプラクティス# どちらも8/20発売の『LLM・AIエージェントシステムベストプラクティス』についてお話します。 よろしくお願いします。

便利だけど知られていないGemini APIの機能 💻 コーディングエージェントをGeminiで構築したい。何から始めればいい？ Geminiの「コーディングエージェントのセットアップ（Coding agent setup）」は、コード生成・修正タスクを自動化するエージェント向けのスキルとセットアップガイドです。 📌 タイトル：コーディングエージェントのセットアップ（Coding agent setup） 🔗 URL： 🧩 概要 コーディングエージェントとは、コードの生成、修正、テスト、デバッグを自律的に行うAIエージェントのこと。Geminiのコーディングエージェントガイドは、このようなエージェントを構築するためのスキル定義、プロンプト設計、ツール連携のベストプラクティスを提供します。Code executionやfunction callingと組み合わせて、実際にコードを書いて動かすエージェントを作れます。 🛠 使い方 ガイドに沿ってエージェントのスキル（コード生成、ファイル操作、テスト実行等）を定義し、Geminiのツール機能と連携します。Code executionでコードを実行し、function callingでファイルシステムやGit操作を呼び出す構成が基本です。プロンプトにはコーディング規約やリポジトリ構造の情報を含めると精度が上がります。 🏗 本番システムへの組み込み方 ・CI/CDパイプライン：PRごとにコーディングエージェントがレビュー・修正提案を自動生成。 ・バグ修正の自動化：エラーログとスタックトレースを渡して、修正パッチを自動生成・テスト。 ・コードマイグレーション：フレームワーク/言語バージョンの移行を、エージェントが段階的に実行。 ・ドキュメント生成：コードを読んでAPIドキュメントやREADMEを自動生成。 💡 ユースケース 🔧 自動バグ修正・パッチ生成 📝 PRの自動レビュー・修正提案 🔄 コードベースのマイグレーション 📚 コードからのドキュメント自動生成 ⚠️ 注意点 エージェントが生成するコードは必ずレビューとテストが必要です。本番コードへの自動マージは人間の承認ステップを挟みましょう。また、エージェントがファイルシステムにアクセスする場合のセキュリティ境界（サンドボックス化）も重要です。 ✨ コーディングの自動化は段階的に。まずはレビュー補助や定型的な修正から始めて、信頼性が確認できた範囲で権限を広げていくのがおすすめです。 #Gemini# #LLM#

便利だけど知られていないClaude APIの機能 🧑‍🏫 エージェントが判断に迷ったとき、「もう一人のAIに相談」できたら便利だと思いませんか？ ClaudeのAdvisor Tool（アドバイザーツール）は、エージェント実行中に助言や推奨を得るためのAnthropic提供サーバーツールです。メインのエージェントとは別の視点でアドバイスを受けられる、ちょっとユニークな機能です。 📌 タイトル：Advisor Tool（アドバイザーツール） 🔗 URL： 🧩 概要 エージェントが複雑な判断をする場面で、自分自身のコンテキストだけでは最善の判断ができないことがあります。Advisor Toolは、Anthropicが提供するサーバー側ツールで、エージェントがツール呼び出しとして「アドバイスを求める」ことができます。メインの推論とは別のモデルインスタンスが助言を返すため、異なる視点や追加の検討を得られます。 🛠 使い方 Messages APIのツール定義にAdvisor Toolを追加します。エージェントは必要に応じて自動的にアドバイスを要求し、返ってきた助言をコンテキストに組み込んで判断を進めます。サーバー側ツールなので、自前の実装は不要です。 🏗 本番システムへの組み込み方 ・意思決定エージェント：重要な判断ポイントでアドバイザーに相談し、セカンドオピニオンを得てから行動。判断の質が上がります。 ・コード生成パイプライン：設計判断が複数ある場面で、アドバイザーにベストプラクティスを確認してから実装方針を決定。 ・カスタマーサポートBot：回答に自信がないケースでアドバイザーの意見を参照し、より確実な回答を生成。エスカレーションの判断にも使えます。 ・マルチステップワークフロー：各ステップの完了時にアドバイザーに進行方針のレビューを依頼し、軌道修正を行う。 💡 ユースケース 🤔 重要判断のセカンドオピニオン 🏗 設計・方針決定の助言 📞 サポート回答の品質向上 🔄 ワークフローの中間レビュー ⚠️ 注意点 アドバイザーへの呼び出しは追加のAPIコールとなり、レイテンシとコストが増えます。すべての判断でアドバイザーを呼ぶのではなく、重要な分岐点に絞って使うのが効率的です。また、アドバイザーの助言は参考情報であり、最終判断はメインエージェントが行う点を理解しておきましょう。 ✨ 一人で考えるより二人で考えるほうが良い判断ができるのは、AIも同じ。まずは判断が難しいステップにアドバイザーを追加してみてください。 #Claude# #LLM#

# AIエージェント開発の意思決定ポイント # 温度（Temperature） 🎯 ポイント 温度パラメータ、全部のタスクに同じ値を設定していませんか？ エージェントシステムにおける温度は「創造性のつまみ」ではありません。構造化出力、ツール呼び出し、ユーザー応答 -- 経路ごとに最適な温度は全く違います。1つのエージェント内でも使い分けるのが基本です。 📋 概要 温度はLLMが次のトークンを選ぶ際の確率分布の「尖り具合」を制御するパラメータです。温度0に近いほど最も確率の高いトークンが選ばれやすくなり、出力は決定論的で安定します。温度を上げると確率分布が平坦化し、低確率のトークンも選ばれるようになるため、出力の多様性と創造性が増します。 AIエージェントでは、構造化出力を生成する場面、ツール呼び出しの引数を組み立てる場面、自由形式のテキストを生成する場面で求められる温度が異なります。温度は単一の固定値ではなく、タスクの種別に応じて動的に切り替えるべき変数です。 🔍 意思決定のポイント 温度の設定は主にtask_variability（タスクの定型度）で決まります。判定フローは明快です 🧭 1. 構造化出力（JSON/関数呼び出し）か？ → 0.0〜0.3 2. 正確性が最優先（事実抽出・分類・要約）か？ → 0.2〜0.5 3. 対話・説明・コミュニケーションか？ → 0.5〜0.7 4. 創作・ブレインストーミング・候補生成か？ → 0.7〜1.0 加えて、failure_cost（失敗コスト）が高いほど温度の上限を下げ、cost_sensitivity（コスト感度）が高い環境ではリトライによるコスト増を見込んで温度を抑えます。 💡 要点と詳細 タスク別の目安値 📊 - 構造化出力（JSON / function calling） → 0.0〜0.3。スキーマ違反の最小化が最優先 - 分類・抽出・データ変換 → 0.0〜0.2。正確性と再現性が命 - 要約・説明・カスタマー対応 → 0.5〜0.7。自然さと正確性のバランス - 創作・ブレスト・候補生成 → 0.7〜1.0。多様性が価値の源泉 - ツール引数の生成 → 0.0〜0.2。関数名・引数名の正確性が不可欠 - 計画・推論 → 0.3〜0.6。多少の探索は有益だが論理の一貫性を保つ 構造化出力の温度はまず0から始めてください。0でもスキーマ違反が出る場合はプロンプトかスキーマの問題です。温度を上げて「偶然正しい出力が出る」ことに依存してはいけません 🚫 ⚖️ トレードオフ 温度が低すぎると対話が機械的で紋切り型になります 🤖 同じ質問に毎回同じ回答を返し、「テンプレート応答」の印象を与えます。Best-of-Nサンプリングも候補がほぼ同一になり、N倍のコストだけかかって実質N=1と同じ結果に。 温度が高すぎると構造化出力が壊れ始めます 💥 JSONのフィールド名が揺れたり、型が合わなくなったり。ハルシネーションも増加し、固有名詞・数値・日付の正確性が崩壊します。ツール呼び出しの不安定化、再現性の喪失も深刻な問題です。 温度によるリトライコストの増加も計測してください。スキーマ違反率が概ね5%を超えたら温度を下げることを検討しましょう。 🛠️ ユースケース エージェント内の経路ごとに温度を変えるのが基本 🔀 計画ステップは0.3〜0.5、ツール呼び出しの引数生成は0.0〜0.2、ユーザー向け応答は0.5〜0.7。モデルを切り替える際に温度も同時に切り替えると自然です。 Best-of-Nを使うなら温度を上げる必要があります。温度0でN=5を生成しても、ほぼ同一の候補が5つ返るだけです。N>1のときは0.5〜0.8に設定し、多様な候補の中からJudgeが最良を選ぶ構成にします。 top_pとの併用には注意 ⚠️ 温度とtop_pを両方変更すると効果が掛け算になり、予測困難な挙動を示します。原則としてどちらか一方だけを調整してください。 #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント 🎯 **ポイント** 全部のタスクに最強モデルを使っていませんか？「Yes/Noの分類」にフラグシップモデルを使うのは、引っ越しにジャンボジェットを飛ばすようなものです。モデル階層化は、コストと品質のバランスを「定数」から「関数」に変える実践的な戦略です。 📋 **概要** モデル階層とは、タスクの種類や難易度に応じて小型・中型・大型のどのクラスのLLMを使うかを制御するダイヤルです。AIエージェントシステムでは、1回のセッション内に分類・抽出のような定型処理と、推論・計画のような高度な処理が混在します。すべてを大型モデルで処理すれば品質は安定しますが、月間コストが桁違いに膨張します。実運用では全リクエストの概ね60〜80%が小型・中型モデルで十分処理でき、大型モデルが本当に必要なのは残りの20〜40%です。 🔍 **意思決定のポイント** このダイヤルは2つの駆動変数で決めます。 🔹 **コスト感度（cost_sensitivity）** — コスト感度が高いほど小型モデルへの振り分けを増やします。全リクエストを大型モデルで処理する場合と比べ、60%を小型（コスト1/10）、20%を中型（コスト1/3）、20%を大型で処理すると、コストは概ね30%程度まで削減できます。 🔹 **リクエスト価値（request_value）** — 価値の高いリクエストほどエスカレーション閾値を下げ、早めに上位モデルを使います。逆にコスト感度が高い場合は閾値を上げ、本当に必要な場合のみエスカレーションします。 まずはタスク種別による静的ルーティングから始めるのが実践的です。分類・タグ付け・抽出は小型、要約・翻訳は中型、推論・計画・コード生成は大型。そこに信頼度ベースのエスカレーション（構造化出力のパースエラー率、回答拒否率などで判定）を重ねます。 💡 **要点と詳細** 📊 モデル階層数は2〜3層が運用しやすいです。4層以上は管理コストが増大します。エスカレーション閾値は信頼度0.7〜0.85が目安で、リクエスト価値が高いほど下げます。 ルーター方式はまずルールベースで始めましょう。LLMをルーターに使うとルーティング自体にコストがかかり、小型モデル1回分に匹敵することもあります。リクエスト量が少ないうちは入力長やキーワードベースのルールで十分です。 障害時には逆方向のフォールバック（大型→中型→小型）も有効です。サーキットブレーカが開いた場合に軽量モデルに切り替えることで、品質は落ちてもサービスを継続できます。縮退レベルをレスポンスのメタデータに含め、クライアント側で品質低下の可能性を表示するのが望ましいです。 ⚖️ **トレードオフ** 📉 小型モデルに偏りすぎると — 複雑な推論タスクで「もっともらしいが間違っている」回答が増えます。計画の途中で矛盾が発生し実行フェーズで失敗、コード生成では構文は正しいが論理的に誤ったコードが生成されます。失敗コストが高いタスクでは、エラー修正コストが節約額を上回ることになります。 📈 大型モデルに偏りすぎると — 単純な分類タスクに100倍のコストをかけ、応答時間が数秒に膨張します。大型モデルのレート制限に達しやすくなり、全リクエストが429エラーの影響を受けるリスクもあります。月間コストの予算超過はサービスの継続性を脅かします。 🛠️ **ユースケース** 📞 **カスタマーサポート** — 質問分類・FAQ回答・感情分析は小型モデル（全体の約70%）、技術的な問題の診断は中型〜大型、返金ポリシー判断は大型モデル。分類結果に応じて適切な層にルーティングします。 📊 **データ分析パイプライン** — フォーマット変換は小型、数値統計はコード（LLM不要）、パターン分析・異常検知の解釈とエグゼクティブサマリは大型。パイプラインの大部分は小型モデルとコードで処理できます。 🔄 **障害時フォールバック** — 通常は大型モデルで推論し、プロバイダ障害時に中型→小型と段階的にダウングレード。全プロバイダ障害なら静的フォールバック。可用性と品質のバランスを動的に調整する構成です。 信頼度の定義は測定可能な指標に落としましょう。「なんとなく自信がない」では運用できません。モデル更新時はルーティング比率の再検証もお忘れなく。 #AIエージェント# #ソフトウェアアーキテクチャ#