# OpenCodeの機能と実践的な使い方 🧰 AIエージェントに「何を許して、何を止めるか」を一行で決められたら安心しませんか。OpenCodeの組み込みツールと権限制御はまさにそれを叶えてくれます。 🏷️ タイトル: 組み込みツール+権限 🔗 URL: 📘 概要 OpenCodeのエージェントは、ファイル編集やシェル実行などを「ツール」を通じて行います。これらは標準で多数組み込まれており、さらに各ツールに対して許可・確認・拒否のポリシーを設定できます。安全性と利便性のバランスを設定ファイルだけで調整できるのが特徴です。 ⚙️ 機能の説明 主な組み込みツールは次のとおりです。 ・`bash`: シェルコマンドの実行（git や npm など） ・`edit`: 既存ファイルの厳密な文字列置換による編集 ・`write`: 新規作成または上書き ・`read`: ファイル読み込み（行範囲指定も可） ・`grep`: 正規表現での検索 ・`glob`: `**/*.js` のようなパターンでのファイル探索 ・`webfetch` / `websearch`: Web取得・検索 ・`lsp` / `apply_patch` / `skill` / `todowrite` / `question` など補助ツール 権限は `permission` フィールドで `allow`（自由実行）・`ask`（毎回確認）・`deny`（禁止）の3状態を指定します。`edit` の権限は `edit`・`write`・`apply_patch` の3つをまとめて支配する点に注意してください。 🛠️ 実践的な使い方 `opencode.json` の `permission` に `"edit": "deny"`、`"bash": "ask"`、`"webfetch": "allow"` と書けば、編集は禁止しつつ bash は都度確認、Web取得は自由、という運用ができます。 MCP由来のツールはワイルドカードでまとめて制御できます。`"mymcp_*": "ask"` のように書けば、そのサーバーの全ツールに確認を要求できます。 💡 ユースケース 本番に近いリポジトリでは `edit` を `deny`、`bash` を `ask` にしておくと、エージェントが計画や調査はできても、勝手にコードを書き換えたり破壊的コマンドを走らせたりしません。逆に使い捨ての検証ブランチでは全許可にして高速に回す、といった切り替えが容易です。 ⚠️ 注意点 標準では全ツールが許可されているため、明示的に絞らないと制限はかかりません。`lsp` ツールは `OPENCODE_EXPERIMENTAL_LSP_TOOL=true`、`websearch`（Exa利用）は `OPENCODE_ENABLE_EXA=1` の環境変数が必要です。`edit` 権限が write/apply_patch まで及ぶ点は見落としがちなので意識しておきましょう。 #OpenCode# #AIエージェント#

# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 棄権閾値｜Abstention Threshold 🎯 ポイント エージェントが「自信がないときに黙る」仕組み、ちゃんと設計していますか？ 棄権閾値とは、エージェントが「自信がない」と判断して回答を棄権し人間にエスカレーションする信頼度スコアの境界線です。低すぎると誤答がユーザーに届き、高すぎるとエスカレーションだらけで自動化の意味がなくなります。誤答コストの大きさに応じてタスクカテゴリごとに異なる閾値を設定する多段構成が正解です🔑 📋 概要 棄権閾値は、エージェントが回答に自信がないときに人間へのエスカレーションを発動する信頼度スコアの基準値です。閾値が低ければ自動解決率は上がりますが誤答リスクも上がり、高ければ安全ですがエスカレーションが増えて人間の負荷と応答遅延が増大します。「間違った回答を自信満々にする」エージェントは信頼を致命的に損ないます。一方で「何でもかんでも聞いてくる」エージェントは導入の意味がありません。この間のバランスを、業務の誤答コストに基づいて精密に設計するのがこのダイヤルの役割です。 🔍 意思決定のポイント このダイヤルは「誤答した場合のコスト」で決めます。 致命的（不可逆・法的リスク・金銭損害）→ 高い閾値（0.85〜0.95）。返金金額の誤り、契約条件の誤案内、医療・法律相談など。少しでも不確実なら棄権。 中程度（修正可能だが手間がかかる）→ 中程度の閾値（0.70〜0.85）。Jiraチケットの優先度誤判定、Salesforceの商談ステージ誤更新など。 軽微（すぐ修正でき影響が限定的）→ 低い閾値（0.50〜0.70）。FAQ回答候補の表示、Slackでの情報検索結果など。多少の誤りは許容。 一律の閾値は避け、タスクカテゴリごとに異なる閾値を設定する多段構成にしてください⚡ 💡 要点と詳細 棄権閾値を機能させるには、信頼度スコアの設計が重要です。4つの算出方法があります： モデルのlogprob — トークンレベルの確率を集約します。分類タスクでは有効ですが、自由形式の回答では使いにくくなります。 自己評価プロンプト — 「回答の確信度を0〜1で評価せよ」と追加プロンプトで問います。キャリブレーションが必要です。 複数回生成の一致度 — 同じ入力を3〜5回生成し、回答の一致率を信頼度とします。コストはかかりますがロバストです。 検索ヒットの関連度スコア — RAGベースの回答では、検索結果の類似度スコアを信頼度の代理指標にします。 計測すべき指標は、自動解決率（エスカレーションせずに完了した割合）、誤答率（自動回答のうち誤っていた割合、目安として2〜5%以下）、不要棄権率（棄権したが正しく回答できていたケースの割合）、エスカレーション後の解決時間、そして信頼度スコアのキャリブレーション（信頼度0.8の回答の実際の正答率が80%前後か）です📊 ⚖️ トレードオフ 閾値が低すぎると、自動解決率は上がりますが誤答がユーザーに到達します。「間違った回答を自信満々にする」ケースが増え、信頼毀損や実害が発生します。特に金銭・法的リスクが絡む業務では、一度の誤答が取り返しのつかない結果を招きます😰 一方、閾値が高すぎると、エスカレーションが増えすぎて人間がボトルネックになります。ユーザーの待ち時間が増加し、エージェント導入の価値が問われます。期待される自動解決率の目安は、致命的リスクで40〜60%、中程度で60〜80%、軽微で80〜95%です。この数字から大きく外れていれば閾値の見直しが必要です⚠️ 🛠️ ユースケース Zendesk顧客対応：返金・解約に関する回答は閾値0.90で厳格に棄権します。間違った返金額を案内するリスクは取れません。一方、商品情報の案内は閾値0.65で自動回答を優先し、スループットを確保します📚 ServiceNow ITサポート：パスワードリセット手順（定型・低リスク）は閾値0.50で積極的に自動対応。権限変更の承認判断（高リスク）は閾値0.90で、不確実なら即エスカレーションします🎯 Salesforce営業支援：商談の受注確度予測は閾値0.75。データが不十分で信頼度が閾値を下回る場合は「判断を保留します。追加情報をご確認ください」と棄権し、誤った確度予測による営業判断ミスを防ぎます🔧 実践のコツ：初期は高めの閾値（0.85）で開始し、2〜4週間のデータ蓄積後に不要棄権率を分析して0.05刻みで下げてください。誤答率が許容範囲を超えたら即座に閾値を戻すこと。信頼度スコアのキャリブレーションは月次で実施し、モデル更新によるドリフトを補正してください。棄権時には「確認中です、担当者におつなぎします」のように、棄権を透明に伝えるUX設計も忘れずに💪 #AIエージェント# #エンタープライズアーキテクチャ#

# Hermes Agentの機能と実践的な使い方 🚀 「昨日の続きから」が一言で始められる。Hermes Agentのセッションは、すべての会話を自動で記録・再開・検索できる長期運用の土台です。 📌 タイトルと機能のURL タイトル: Sessions URL: 📝 概要 セッションは、CLI・Telegram・Discord・Slackなどあらゆる入口での会話を自動保存する仕組みです。完全なメッセージ履歴をSQLiteに永続化し、後から再開したり全文検索で過去のやり取りを掘り出したりできます。プラットフォームごとに文脈が分かれるため、「チャットごとに別の話題」を自然に保てます。 🔧 機能の説明 ・履歴は `~/.hermes/state.db`（SQLite、WAL モード）に保存され、メタデータ・全メッセージ・トークン数・FTS5 全文検索インデックスを管理します。 ・アクティブなコンテキストには現在の会話ウィンドウだけを読み込み、過去の全バイトは展開しません。画像は説明文に、音声は文字起こしに、文書は要約に変換して扱います。 ・最初のやり取りの後、バックグラウンドの補助モデルが3〜7語の説明的なタイトルを自動生成します（遅延なし）。 ・セッションはソースごとに決定論的なキーで識別され、DM・グループ・スレッドで形式が分かれます。 🛠 実践的な使い方 ・直近のCLIセッション再開: `hermes --continue`（または `-c`）。タイトル指定なら `hermes -c "project name"`、ID指定なら `hermes --resume `。 ・一覧・検索・管理: `hermes sessions list --limit 50 --source telegram` / `hermes sessions export backup.jsonl` / `hermes sessions prune --older-than 90 --yes` / `hermes sessions stats`。 ・手動命名: チャット内で `/title my project`、または `hermes sessions rename "new title"`。 ・エージェント自身も `session_search` ツールでFTS5検索を行い、「前にやった件」と言うと自動で過去会話を参照します。 ・`/handoff telegram` でCLIの会話を全文と共にメッセージング先へ引き継げます。 🎯 ユースケース ・昨日のリファクタ作業をそのまま再開し、中断前の文脈を引き継ぐ。 ・「あのとき何を決めたか」を全文検索で素早く参照する。 ・Telegram・Discordなど入口ごとに文脈を分離し、混線を防ぐ。 ・長期運用エージェントの作業履歴データベースとして活用する。 ⚠️ 注意点 ・自動タイトル付けはセッションごとに1回のみで、既にタイトルがあればスキップされます。 ・メディアのバイト列は再送されず、派生テキストやファイルパスのみが後続の文脈に残ります。 ・自動プルーニング（` ・スレッド非対応プラットフォームの共有ホームチャンネルでは、本来共有したいグループ会話の扱いが理想的でない場合があります。 #HermesAgent# #AIAgents#

# AIエージェントをソフトウェアに組み込むプラクティス # 読取自由・書込ゲート 🎯 「全ツール呼び出しに承認を求める」設計は、承認疲れで自壊します。 読取と書込を非対称に扱うだけで、安全性と生産性の両立が実現できます。承認すべき操作に人間の注意を集中させましょう。 🔥 解決する課題 エージェントのツール呼び出しには副作用のある操作とない操作が混在しています。すべてに一律の承認を求めると、読取が大半を占める実運用では承認疲れが発生し、肝心の書込操作の承認が形骸化してしまいます。かといってすべてを自由にすれば、不可逆な書込操作で取り返しのつかない変更が走るリスクが残ります。 💡 提案パターン ツール呼び出しを「読取（検索・取得・参照）」と「書込（作成・更新・削除・送信）」に二分し、読取は自由に許可、書込にだけ認可・検証・承認・監査のゲートを設けます。R/W分類はツール定義時に静的に付与し、LLMの判断には委ねません。書込ゲートの厳格度は可逆性で段階化し、不可逆操作（メール送信・決済）は人間承認必須、可逆操作（下書き保存）はポリシー検証のみとします。これにより承認疲れを劇的に減らしつつ、副作用の安全性を維持できます。 ✅ 選定条件 使うとき： - 読取と書込が混在し、読取が多数を占める - 不可逆な書込操作（メール送信、決済、本番DB変更）が含まれる - 承認疲れを防ぎ、人間のレビュー帯域を高リスク操作に集中させたい 使わないとき： - 読取自体が機密データへのアクセスを含む場合（個人情報検索など）は、読取にも認可が必要 - 全操作が読取専用で書込がそもそも存在しない場合 - 実験環境で全操作が可逆かつ低コストな場合 ⚠️ 落とし穴 - R/W分類をLLMに任せてはいけません。インジェクションで書込ツールが「読取」と判断される経路を作ります - 「読取だが副作用がある」操作（API呼び出し回数カウント、閲覧履歴記録など）を見落とさないでください - 可逆な書込と不可逆な書込を同じ厳格度にすると、承認疲れの問題が再発します 🔧 実装方針 - ツール定義時にtype（read/write）とgate種別（none/auto/human_approval）を静的に付与し、実行時にLLMが分類を変更できない構造にします - 読取パスではメタデータのみをログに記録し、書込パスでは入力検証・ゲート判定・実行・監査ログの全量記録をパイプラインとして実装します - 書込ゲートの厳格度をreversibleフラグで段階化し、不可逆操作にはdry-runの前段必須化も組み合わせます - ゲート判定ロジックはゲートウェイ層のコードで強制し、プロンプトによる制御は一切使用しません #AIエージェント# #ソフトウェアアーキテクチャ#

# Claude Agent SDKの便利で実践的な使い方 🤖 サブエージェントに専門タスクを委譲して、メインコンテキストをリーンに保てます。 サブエージェントは、特定のサブタスクを専門エージェントに委譲し、メインエージェントのコンテキストを汚さずに並列・専門処理を実現する機能です。 📌 タイトル：SDK のサブエージェント 🔗 URL： 🧩 概要 `agents` パラメータで専門エージェントを定義し、メインエージェントが `Agent` ツール経由で呼び出します。各サブエージェントには独自のプロンプト・ツール制限・モデル設定が可能で、結果は要約としてメインに返されます。 🛠 使い方 `agents` パラメータに `AgentDefinition`（`description`・`prompt`・`tools`・`model` 等）を定義します。`allowed_tools` に `"Agent"` を含めるとサブエージェント呼び出しが自動承認されます。各サブエージェントは独自のツール制限・プロンプト・モデルを持てます。 🏗 実践的な使い方 ・`research-assistant` サブエージェントに数十ファイルの探索を委譲し、親エージェントには要約だけ返します。メインコンテキストがリーンに保たれます。 ・`style-checker` / `security-scanner` / `test-coverage` を同時実行し、コードレビュー時間を数分→数秒に短縮します。 ・`database-migration` サブエージェントに SQL ベストプラクティス・ロールバック戦略のプロンプトを持たせ、メインを汚さず専門タスクを処理します。 ・ファクトリ関数で実行時条件に応じて `model: "opus"` / `sonnet` を動的に切り替えます。 💡 ユースケース 🔍 大量ファイル探索の委譲 ⚡ 並列コードレビュー（style/security/coverage） 🎯 専門知識エージェントへのタスク分割 ⚠️ 注意点 サブエージェントは自分のサブエージェントを生成できません（1 段階のみ）。大規模オーケストレーションには `Workflow` ツール（TS v0.3.149+）を使用してください。`agentId` と `session_id` をキャプチャすれば `resume` でフォローアップも可能です。 #ClaudeAgentSDK# #AI#

# Claude Agent SDKの便利だけど知られていない機能 🌍 セッション途中で権限を変えたい？ストリーミング中に権限モードを動的に切り替えられます！ Claude Agent SDKでは、セッション実行中に `set_permission_mode()` を呼ぶだけで、権限モードを即座に変更できます。 📌 タイトル：ストリーミング中の権限モード動的変更 🔗 URL： 🧩 概要 `set_permission_mode()`（Python）/ `setPermissionMode()`（TypeScript）を使うと、セッションの途中で権限モードをリアルタイムに変更できます。新しいモードは即座に有効となり、以降のすべてのツールリクエストに適用されます。「最初は厳格に、信頼が築けたら緩める」という段階的な権限管理が実現できます。 🛠 使い方 ```python # Python - 段階的に権限を緩和する例 import asyncio from claude_agent_sdk import ClaudeSDKClient, ClaudeAgentOptions async def main(): async with ClaudeSDKClient( options=ClaudeAgentOptions( permission_mode="default", # まずはデフォルトで開始 ) ) as client: await client.query("このコードをリファクタリングしてください") # アプローチを確認後、編集を許可 await client.set_permission_mode("acceptEdits") async for message in client.receive_response(): if hasattr(message, "result"): print(message.result) ``` ```typescript // TypeScript const q = query({ prompt: "Refactor this code", options: { permissionMode: "default" } }); // アプローチ確認後に編集を許可 await q.setPermissionMode("acceptEdits"); for await (const message of q) { if ("result" in message) console.log(message.result); } ``` 🏗 本番システムへの組み込み方 ・「plan → 確認 → acceptEdits」のワークフローで、安全なステップバイステップの自動化を実現します ・ユーザーの信頼度や操作の進行状況に応じて、段階的に権限を拡大するインタラクティブなアプリを構築できます ・エラー検出時に権限を引き締める「フォールバック」パターンにも活用できます ・監視システムと連携し、異常検知時に自動的に制限的なモードへ切り替えることも可能です 💡 ユースケース 🔐 コードレビュー後に編集権限を付与する対話型ワークフロー 📈 タスクの進捗に応じて権限を段階的に拡大するプログレッシブな自動化 🛡 異常を検知したら即座に制限モードに切り替える防御的エージェント ⚠️ 注意点 ・新しいモードは即座に有効になるため、切り替えのタイミングに注意してください ・モード変更は現在のセッション内でのみ有効です ・`bypassPermissions` や `auto` モードに切り替えた場合、サブエージェントにも継承される点に注意が必要です ✨ 権限の動的変更は「最初は安全に、必要に応じて柔軟に」を実現する強力なツールです。段階的な信頼構築のワークフローにぜひ活用してください！ #ClaudeAgentSDK# #AIAgent#

開発が加速している。 これがモデルを重ねる毎に学習の手法を学んできた結果か、それともGPUの性能向上によるもの、データが整備されたからか。たぶん色々な要因で学習・リリース頻度を上げてるのだろうけど。

便利だけど知られていないGemini APIの機能 🔄 レイテンシは多少ブレてもいいから、とにかくコストを抑えたい。そんなワークロードありませんか？ Geminiの「Flex inference（フレックス推論）」は、低コストでレイテンシが変動する推論ティアです。リアルタイム性よりコスト効率を重視するワークロードに最適な選択肢です。 📌 タイトル：Flex inference（フレックス推論） 🔗 URL： 🧩 概要 通常の推論ティアはレイテンシの安定性を優先しますが、すべてのタスクにそれが必要なわけではありません。Flex inferenceは空きリソースを活用して処理するため、応答時間にブレがある代わりに低コストで利用できます。バッチAPIほどの遅延はなく、かといって通常ティアほどの即時性も求めない「ちょうどいい」位置づけです。 🛠 使い方 リクエスト時に推論ティアとしてFlexを指定するだけ。APIの呼び出し形式やレスポンス形式は通常と同じなので、既存コードの変更はティア指定の追加のみで済みます。レイテンシが許容範囲内かを事前にテストしてから本番導入するのがおすすめです。 🏗 本番システムへの組み込み方 ・バックオフィス処理：社内向けの要約・分類タスクなど、ユーザーが画面の前で待たない処理に。 ・非同期ワーカー：キューから取り出して処理するワーカーで、多少の遅延が許容される場面に。 ・開発/ステージング環境：本番前のテストや実験で、コストを気にせず大量にリクエストを投げたいとき。 ・コンテンツの下書き生成：即座に公開しない下書きや素案の生成に。 💡 ユースケース 📋 社内向けの非リアルタイム処理 🔧 非同期キューベースのワーカー処理 🧪 開発・テスト環境での大量実験 📝 公開前の下書き・素案生成 ⚠️ 注意点 レイテンシが変動するため、ユーザーが応答を待つ対面的なUI（チャットbot等）には不向きです。ピーク時にはレイテンシが大きく伸びることもあるため、SLAが求められる場面ではPriority inferenceの方が適切です。コスト削減の効果は利用パターンによって異なるので、まずは計測から。 ✨ すべてのリクエストに最高速の推論は要りません。コストが効く場面を見極めて、Flexで賢く使い分けてみてください。 #Gemini# #LLM#

# Cursorの機能と実践的な使い方 🧩 「あの作業、毎回同じ手順なのにAIに毎回説明している」を卒業しませんか。CursorのSkillsは、定型ワークフローを部品化してエージェントに覚えさせる仕組みです。 🏷️ タイトル: 再利用ワークフロー(SKILL.md) 🔗 URL: 📘 概要 Skillsは、特定ドメインのタスクの手順をエージェントに教える、ポータブルでバージョン管理可能なパッケージです。スクリプト・テンプレート・参照資料をまとめ、エージェントがツール経由で実行します。Rulesの進化形にあたり、文脈に応じて自動適用したり、スラッシュコマンドとして明示的に呼び出したりできます。 ⚙️ 機能の説明 各スキルは `SKILL.md` を中心に構成され、先頭のYAMLフロントマターで挙動を定義します。 ・`name`: 親フォルダ名と一致する小文字の識別子(必須) ・`description`: 何のためのスキルかと適用場面。エージェントがこの説明を読んで使うか判断します(必須) ・`paths`: glob パターンで対象ファイル種別にスコープを限定(任意) ・`disable-model-invocation`: `true` にすると自動適用されず `/skill-name` でのみ呼び出されるスラッシュ専用に(任意) 配置場所は階層的で、プロジェクトは `.cursor/skills/`(または `.agents/skills/`)、ユーザー全体は `~/.cursor/skills/` です。ルートは再帰的に走査され、ネストしたサブディレクトリも発見されます。スキルフォルダには `scripts/`(実行コード)、`references/`(必要時に読む資料)、`assets/`(テンプレや画像)を同梱できます。 🛠️ 実践的な使い方 たとえば `.cursor/skills/api-endpoint/SKILL.md` のフロントマターに `name: api-endpoint`、適用場面を書いた `description`、対象を絞る `paths: "src/api/**/*.ts"` を置き、本文に「ルートを registry に登録」「入力は zod で検証」「テストを必ず追加」といった手順を箇条書きします。 自動適用させたくない場合は `disable-model-invocation: true` を足し、Agentチャットで `/api-endpoint` と打って明示的に呼び出します。 💡 ユースケース モノレポでは各アプリ配下に `.cursor/skills/` を置くと、そのディレクトリ内のファイルへ自動的にスコープされ、`paths` を書かずに済みます。リリース手順・移行スクリプト・コードレビュー観点などを共有し、チーム全員が同じワークフローで作業できます。既存資産は Cursor 2.4 同梱の `/migrate-to-skills` で変換でき、「Apply Intelligently」(`alwaysApply: false`)なルールはスキルへ、スラッシュコマンドは `disable-model-invocation: true` 付きスキルへ自動移行されます。 ⚠️ 注意点 スキルの識別名は `SKILL.md` を含むフォルダ名から決まり、親カテゴリ名ではありません。旧来の `globs` フィールドは非推奨で、今は `paths` を使います。`/migrate-to-skills` は `alwaysApply: true` のルールやユーザーレベルのルールは移行しないため、これらは手動対応が必要です。 #Cursor# #AIコーディング#

# ADK 2.0の便利だけど知られていない機能 🌍 毎回同じシステムプロンプトやツール定義をLLMに送信するのは、コストもレイテンシも無駄だと感じませんか？ ADK 2.0のコンテキストキャッシュ（ContextCacheConfig）は、繰り返し送信されるコンテキストデータをキャッシュし、LLMの呼び出しコストとレイテンシを削減する機能です。Gemini 2.0以降、Python v1.15.0以降、Java v0.1.0以降で利用可能です。 📌 タイトル：コンテキストキャッシュ (ContextCacheConfig) 🔗 URL： 🧩 概要 ContextCacheConfigは、LLMに送信するコンテキスト（システムプロンプト、ツール定義、会話履歴の固定部分など）をキャッシュすることで、トークン消費を削減します。3つの主要パラメータがあります。min_tokensはキャッシュを有効にするための最小トークン数のしきい値（デフォルト0）、ttl_secondsはキャッシュの有効期限（デフォルト1800秒＝30分）、cache_intervalsはキャッシュの最大再利用回数（デフォルト10回）です。これらをAppオブジェクトに設定することで、自動的にキャッシュが適用されます。 🛠 使い方 ContextCacheConfigを作成し、Appに設定します。 ```python from import App from google.adk.context import ContextCacheConfig cache_config = ContextCacheConfig( min_tokens=1000, # 1000トークン以上でキャッシュ有効 ttl_seconds=3600, # 1時間キャッシュを保持 cache_intervals=20, # 最大20回再利用 ) app = App( agent=my_agent, context_cache_config=cache_config, ) ``` min_tokensを適切に設定することで、小さなコンテキストでは通常送信し、大きなコンテキストのみキャッシュするように制御できます。 🏗 本番システムへの組み込み方 ・大きなシステムプロンプトや多数のツール定義を持つエージェントで特にコスト効果が高い ・ttl_secondsをワークロードのパターンに合わせて調整する（短い会話→短いTTL、長い会話→長いTTL） ・cache_intervalsをリクエスト頻度に応じて設定し、キャッシュの鮮度とコスト削減のバランスを取る ・コスト削減効果をモニタリングし、パラメータを継続的に最適化する 💡 ユースケース 💰 大規模なシステムプロンプトを持つエージェントのAPI呼び出しコストを削減 ⚡ 繰り返しのツール定義送信を省略してレスポンスレイテンシを改善 🔁 高頻度のリクエストが発生するチャットボットでトークン消費を最適化 📋 固定的なコンテキスト（ルール、ガイドライン等）の再送信を効率化 ⚠️ 注意点 Gemini 2.0以降のモデルでのみ利用可能です。キャッシュが有効な間はコンテキストの変更が反映されないため、頻繁にシステムプロンプトを変更する場合はttl_secondsを短く設定してください。また、cache_intervalsを超えると新しいキャッシュが作成されるため、コスト最適化の効果が変動する可能性があります。 ✨ コンテキストキャッシュは、特にコンテキストが大きく頻繁にリクエストされるシナリオで、コストとパフォーマンスの両面で大きな改善をもたらします。 #ADK# #AIAgent#

MCPがHTTPになっていって結局REST APIに色々寄っていってる気がする。 REST APIの課題対策としてgRPCやGraphQLが出たと思うけど、適当でもすぐ使える簡単さが常に残っててエンジニアリングとして学びがある。

# Neo4jの機能と実践的な使い方 🚪 データ投入の方法選びを最初に間違えると、後工程がすべて遅くなります。Neo4jの「インポート方法 選択ガイド」は、規模と頻度から最適な入口を決めるためのハブページです。 🏷️ タイトル: インポート方法の選択ガイド 🔗 URL: 📘 概要 Neo4jへのデータ投入には複数の手段があり、それぞれ得意な規模・実行モード（オンライン/オフライン）・権限要件が異なります。このページは個別の手順書ではなく、「どの方法を選ぶべきか」を最初に判断するための入口にあたります。 ⚙️ 機能の説明 主な選択肢は次のとおりです。 ・Data Importer: ブラウザGUIでCSVをドラッグ＆ドロップし、ノード/リレーションシップに視覚的にマッピング。Cypher不要で、検証・プロトタイピング向き。 ・`LOAD CSV`: Cypherで書く汎用的な取り込み。オンライン（DB稼働中）で動き、非管理者でも実行可能。数十万〜数百万行クラスまで。 ・`neo4j-admin database import`: オフラインのバルクローダ。空のDBに対し、ストアファイルへ直接書き込むため最速。数十億規模の初期構築向け。 ・コネクタ/APOC: Apache Spark / Kafka / CDC による継続的同期や、JSON/XML/XLSなど多様な形式の取り込み。 🛠️ 実践的な使い方 規模と頻度で入口を決めるのが実践の第一歩です。 ・数千件のマスタを手早く → Data Importer（GUI） ・数百万件の定期ロード/差分ロード → `LOAD CSV`（`MERGE`で冪等化） ・数十億件のワンショット初期構築 → `neo4j-admin database import`（オフライン） ・常時の継続同期 → Kafka / CDC / Spark コネクタ いずれの経路でも、取り込み前にキー列へ一意制約を張るのが共通の定石です。 ```cypher CREATE CONSTRAINT person_id IF NOT EXISTS FOR (p:Person) REQUIRE IS UNIQUE; ``` 💡 ユースケース プロジェクト初期に、PoCはData Importer、本番初期構築は`neo4j-admin import`、日次差分は`LOAD CSV`、というように経路を分けて設計します。これにより「検証は軽く速く、本番投入は最速」を両立できます。 ⚠️ 注意点 ・`neo4j-admin import`は空のDB専用かつオフラインのため、稼働中DBには使えません。 ・`LOAD CSV`は行数が数十万〜数百万に近づくとメモリ問題が出やすく、`CALL { } IN TRANSACTIONS`での分割が必要です。 ・継続同期（Kafka/CDC）は初期ロードとは別物として、組み合わせて設計します。 ・このページは入口です。各方式の細部は必ずリンク先の個別ドキュメントで確認してください。 #Neo4j# #DataImport#

便利だけど知られていないClaude APIの機能 📁 同じファイルを何度もBase64で送り直すの、もう疲れていませんか？ ClaudeのFiles API は、ファイルをアップロードして複数のリクエストで再利用できる仕組みです。毎回ファイルを添付し直す必要がなくなり、コストもレイテンシも削減できます。 📌 タイトル：Files API 🔗 URL： 🧩 概要 画像やPDF、テキストファイルをClaudeに処理させたいとき、従来はリクエストのたびにBase64エンコードしたファイルデータを送る必要がありました。Files APIを使うと、ファイルを一度アップロードしてIDを取得し、以降はそのIDを参照するだけで同じファイルを複数のリクエストで使い回せます。転送量の削減とPrompt Cachingとの相性の良さがポイントです。 🛠 使い方 まずFiles APIでファイルをアップロードし、返されたfile_idを保存します。Messages APIでそのファイルを使いたいときは、file_idを参照するコンテンツブロックを使います。同じファイルに対して複数の質問をしたり、異なるプロンプトで処理したりする場合に、毎回ファイルデータを送る必要がありません。 🏗 本番システムへの組み込み方 ・文書分析サービス：ユーザーがアップロードしたPDFを一度保存し、複数の分析（要約・質問応答・データ抽出）を順次実行。毎回PDFを送り直さない。 ・画像分析パイプライン：大量の画像を事前アップロードし、バッチで分析。転送コストとレイテンシを大幅に削減。 ・マルチターン文書チャット：参照文書をアップロードしておき、何度も質問を重ねる対話型文書QAに。 ・テンプレート管理：定型文書やスタイルガイドをファイルとして保存し、生成リクエストで繰り返し参照。 💡 ユースケース 📄 PDF・文書の繰り返し分析 🖼 画像のバッチ処理 💬 文書ベースのマルチターンチャット 📋 テンプレートファイルの再利用 ⚠️ 注意点 アップロードしたファイルには保持期限があるため、長期間参照する場合は期限を確認してください。また、ファイルのサイズ制限にも注意が必要です。大量のファイルを管理する場合は、file_idのライフサイクル管理を仕組み化しておきましょう。 ✨ 同じファイルに何度もお金を払うのは無駄。一度アップロードして使い回すだけで、コストも開発体験も改善します。 #Claude# #LLM#

# ADKの便利で実践的な使い方 ✋ 「本当にこのメールを送信しますか？」— ADKのAction Confirmationsは、不可逆な操作の前にユーザー確認を挟む、安全なエージェント構築のための仕組みです。 📌 タイトル：Action Confirmations — 不可逆操作の事前確認 🔗 URL： 🧩 概要 ADKのAction Confirmationsは、メール送信、データ削除、決済処理など、取り消しが困難な操作の実行前にユーザーの明示的な承認を求める機能です。エージェントが「送信してよいですか？」と確認し、ユーザーが承認した場合のみ実行されます。これにより、自律的なエージェントでありながら、重要な判断ポイントでは人間のコントロールを維持できます。 🛠 使い方 確認付きツールの定義方法です。 確認付きツールを定義するには、`google.adk` から `Agent` と `ToolContext` をインポートします。`send_email(to: str, subject: str, body: str, tool_context: ToolContext)` 関数では、実際の送信前に `tool_context.actions.request_confirmation(message=...)` を呼び出し、宛先・件名・本文のプレビューを含む確認メッセージを表示します。ユーザーが承認した場合のみ、メール送信処理が実行されます。同様に `delete_records(table: str, condition: str, tool_context: ToolContext)` では、削除対象の件数を事前にカウントし、確認メッセージに件数を含めてユーザーに承認を求めます。これらのツールを `Agent` の `name="admin_assistant"`、`model="gemini-2.5-flash"` に `tools` として渡します。 🏗 実践的な使い方 **確認が必要な操作の判断基準**: 以下の操作には確認を付けることを推奨します。 - 外部への送信（メール、メッセージ、API呼び出し） - データの変更・削除 - 課金が発生する操作 - 権限変更やアクセス制御の変更 決済処理の例として `process_payment(amount: float, currency: str, recipient: str, tool_context: ToolContext)` を定義します。この関数では `tool_context.actions.request_confirmation(message=...)` で送金先・通貨・金額を含む確認メッセージを表示し、ユーザーの承認後に `payment_gateway.charge(amount=..., currency=..., recipient=...)` を実行して決済を処理します。 **確認メッセージの設計**: 確認メッセージには、操作の対象・影響範囲・不可逆性を明確に記載します。ユーザーが判断に必要な情報を過不足なく提供しましょう。 **段階的な確認**: 複数のステップがある場合、各ステップで確認を取るか、最終ステップでまとめて確認するかを設計します。ユーザー体験とのバランスを考慮してください。 💡 ユースケース 📧 メール・メッセージの送信確認 🗑️ データベースレコードの削除確認 💳 決済・送金の実行確認 🔐 権限変更・アクセス制御の変更確認 ⚠️ 注意点 - 確認が多すぎるとユーザー体験が悪化します。本当に不可逆な操作に絞って確認を設定してください。 - 確認メッセージが不十分だと、ユーザーが適切な判断を下せません。操作の影響を具体的に記載しましょう。 - バッチ処理や自動化パイプラインでは確認がボトルネックになります。自動化が必要な場面では確認をスキップする設計も検討してください。 ✨ Action Confirmationsを適切に設定することで、エージェントの自律性と人間の安全管理を両立できます。「取り返しのつかない操作」にだけ確認を入れるのがコツです！ #ADK# #AIAgent#

AIエージェントをエンタープライズシステムに組み込むプラクティス 【スーパーバイザ / ルーター】 💡 全社AIに「何でも聞ける」を実現するカギは、裏側の賢い交通整理。安価な分類器がリクエストを最適なドメインエージェントへ瞬時に振り分けます。 🔥 解決する課題 - すべての機能を1つの巨大プロンプトに詰め込むと品質が劣化する - ドメインごとに最適化されたプロンプト・ツール・モデルを使い分けられない - 全リクエストを最高性能モデルで処理するとコストが破綻する - 分類不能なリクエストが迷子になる 🏗️ 提案パターン 安価で高速な小型分類器がユーザーの意図を判定し、営業・IT・人事・開発などの専門エージェントに委譲します。曖昧な入力には聞き返しで意図を確定させてから振り分けます。委譲先には権限上限・コスト上限・タイムアウトを引き継ぎ暴走を防止。分類不能な場合はデフォルトエージェントまたは人間へのフォールバック経路を必ず用意します。 ✅ 選定条件 - 向き：多様な業務をカバーする全社展開、複数のドメインエージェントが存在する環境 - 不向き：単一ドメインで完結するエージェント（ルーティング不要） ⚠️ 落とし穴 - ルーティング誤りのコストを過小評価しがち（小型モデルで複雑タスクを処理→品質劣化） - 分類精度を実測せず固定ルールだけに頼ると、業務変化に追従できない - フォールバック経路がないと、未知のリクエストが無限ループに陥る 🛠️ 実装方針 1. 意図分類にはファインチューニング済み軽量モデル（distilBERT等）またはルールベース分類器を使い、レイテンシとコストを最小化します 2. ルーティングテーブルを設定ファイル（YAML/JSON）で管理し、ドメインエージェントの追加・変更をコード変更なしで対応できるようにします 3. 分類不能時のフォールバック経路（デフォルトエージェントまたはSlack経由で人間へエスカレーション）を必ず実装します 4. 委譲先エージェントには権限上限・コスト上限・タイムアウトをパラメータとして引き継ぎ、OPA/Cedarでポリシーを一元管理します 5. 分類精度をA/Bテストと週次レポートで継続計測し、誤ルーティング率に応じて分類器を再学習します #AIエージェント# #エンタープライズアーキテクチャ#

8月のMLOps/LLMOps/AgentOps勉強会は8/11（火）開催です！ ご登壇はSnowflake 澁井 @cv_usk 『ソフトウェアにLLM/AIエージェントを組み込むための実践ガイド』、LegalOn 打田様『(仮)マルチモーダルレイクハウス Lance/LanceDB 紹介』になります。 ぜひご参加ください！ #mlopsコミュニティ#

9月の勉強会を9/29（火）開催で公開しました！ ご登壇はDMM @matsui_tk 様『AI駆動開発で仕様はどこまで書くべきか？ ― 人とAIの責務境界から考える開発プロセスの実践』、Mento @qluto 様『正解のない対話の品質をどう運用するか ―― 自由度の高いLLMコーチングプロダクトの評価と継続改善』になります。 ぜひご参加ください！ #mlopsコミュニティ#