世界を動かす技術を、日本語で。
これをシェアしてくれてありがとう。実は、クライアントのリクエストに基づいて、私のSaaSソリューションにエージェントを統合することを検討し始めたところなんだ。正直なところ、エージェントに関する経験はまだあまりないから、特にベストプラクティスや実装のロードマップについてアドバイスをもらえると嬉しいな。目標は、会社の文化を学び反映できるものを作ること、状況に応じた質問に答えること（例えば「この場合はどうする？」）、ドキュメントのエラーチェックを手伝うこと、そして一般的に役立つ内部アシスタントとして機能することなんだ。これらはすべて、クライアントが自社の知識やワークフローに合ったツールを求めているからなんだよね。こういうのって、品質や信頼性の面で実現可能なのかな？それに、幻覚の問題を超えて、考慮すべき大きなセキュリティや障害の懸念はあるかな？
エージェントの複雑さは、比較的シンプルなものから、あなたが望む複雑さのレベルまで様々だよ。だから、あなたのプロジェクトは実現可能そうだけど、ちゃんとした答えを得るためにはいくつかの探索が必要だね。信頼性、品質、セキュリティに関しては、エージェントシステムを実装することを学ぶのと同じくらい、エージェントシステムを観察することを学ぶのも重要だよ。エージェントやLLMベースのソリューションは、実際に機能していることを観察しないと効果が証明されないから、実験やテスト、モニタリングは必須なんだ。セキュリティの懸念については、LLM向けのOWASPトップ10をチェックしてみるといいよ： https://owasp.org/www-project-top-10-for-large-language-mode... LLMやエージェントには、新たな脆弱性があるからね。
https://github.com/humanlayer/12-factor-agents のファンなんだ。これが、完全に制約のないデモやMCPベースのソリューションではなく、アプリでの使用のためにシステムを構築する核心に迫っていると思うから。特に、LLMの呼び出しを構造化された出力を持つライブラリメソッドとして扱う（ファクター4）ことで、セキュリティや信頼性に関する懸念を大幅に減らせるし、自分の制御フローを持つ（ファクター8）ことも重要だよ。エージェントが制約のない入力でツールを呼び出すなんてことは、絶対にあってはならない。
ドキュメントを取り込んで、内部アシスタントで自然言語を使って組織のドキュメントを検索するのは、RAGの良いユースケースに思えるね。エージェントは、自律的に一連のアクションを計画・実行する必要があるときに最適なんだ。両者を組み合わせることもできるけど、いつ組み合わせるかはユースケースによるね。OpenAIのアプローチが好きで、エージェントをいつどのように使うかの思考過程を示しているところが特に良いと思うよ。
他の人たちがあなたのコメントに基づいて良いアドバイスをくれたけど、もう少し深く掘り下げるために、約30分の（ビデオ）通話に興味ある？もっと具体的な提案ができると思うよ。
私の意見では、このガイドは「エージェント構築のための理論的ガイド」と呼ばれるべきだったね。実際には、役立つことをするエージェントを作りたいなら、そんな風には作れないよ。それに、提供されている例は実用的でないだけでなく、悪い実践になる可能性もある。ほとんどのモデルが特にラテン系言語に対してうまく機能するのに、なぜ言語翻訳エージェントの管理パターンが必要なの？実際には、単一のLLMの方がコスト効率が良いだけでなく、全体的なユーザー体験にも良いんだ。それに、プロンプトは本当に重要な要素なのに、ほとんど言及されないんだよね。実際には、問題や解決策を高レベルで数行で説明するだけでは済まない。プロンプトは複雑で、非常にアートな形式なんだ。正直に言うと、科学的な裏付けは全くなくて、直感だけなんだ。でも、実際にはエージェントのパフォーマンスに大きな影響を与えるんだ。このガイドは、開発者にエージェントの構築方法を教育することを目的としているわけではなく、高レベルの理解が必要なビジネスエグゼクティブや意思決定者向けなんだ。実用的な実装の詳細には触れず、開発者が実際に直面する技術的な課題や複雑さを軽視しているよ。
何か良い実用的なガイドってある？
ツールが唯一重要なもので、そこに焦点を当てるべきだよ。「エージェント」という別の概念にこだわるのは愚かだ。特定のエージェントフレームワークに縛られるのは無意味だよ；それはただのLLMを呼び出すwhileループで、JSON/XMLパーサーに接続されているだけなんだから。ツールがエージェントの有用な機能を定義し、形作るもので、MCPを通じてほぼすべてのエージェントプロセスと簡単に共有できるんだ。
そうだね、エージェントのツールキットを複数の「エージェント」に分割する意味があるのか疑問に思うよ—水平スケーリングを除いて。なぜ一つのプロセスが他のプロセスがアクセスできないAPIにアクセスできるべきなの？認証やシークレットはともかく、機能性はどうなの？
マルチエージェントシステムでスコープ付きの権限を解決した人いる？例えば、ユーザーがオーケストレーターエージェントに以下のことを頼むとする：1) 自分のリポジトリでGitHubの問題を検索する。2) 問題を修正してGitHubにプッシュする。3) このバグに関連するタスクをJiraで検索して、ステータスを更新する。4) 修正したことをチームに通知するためにSlackにメッセージを投稿する。これが会社の1000人のユーザーに利用可能なエージェントだと仮定しよう。特定のユーザーのために、システムはどのようにGitHub、Jira、Slackの必要な権限を取得するの？ユーザーが各アクションを承認するなら、タスクがエージェント間で伝播する際に答えは明らかだけど、ハンズフリーでどうやってこれを実現するの？ユーザーが最初のプロンプトを送信した後、オーケストレーターエージェントがGitHubエージェントを呼び出す前に、必要な権限を一度だけ承認することにしか同意しないと仮定しよう。これについてアドバイスをくれる人がいたら、めっちゃ感謝する！ありがとう！
うん、これのためにPolykeyを開発してるよ。話し合うためにメール送った。
これをサービスアカウントのようなもので解決すると思う。「エージェント」にアイデンティティを与えるんだ。「CodeBot」とかなんでもいいけど、それがJiraの情報を読む権限やSlackに通知を送る権限、GitHub APIにアクセスする権限を持つアクターになる。そしたら、誰がそのエージェントに何をさせる権限を持っているかを管理して、すべてを詳細にログに残す。
Arcade.devでは、各エージェントに対してoAuthスコープとトークンの永続性を使ってるよ。最初のツール-ユーザーの組み合わせごとに承認が必要だけど、その後は記憶される。
同様のガイドはここから — Google: https://ia600601.us.archive.org/15/items/google-ai-agents-wh... Anthropic: https://www.anthropic.com/engineering/building-effective-age...
彼らが挙げた例のエージェントには、普通の「ダム」（知能がないって意味ね）サービスで十分だったと思う… だから、私にとってうまくいった例を挙げると、Wasmerっていうアプリホスティングのスタートアップで働いてて、結構な数のアプリをホストしてるんだ。その中には悪意のあるものもある。だから、悪意のあるアプリを効果的に検出するために、Hermanっていうアプリベッターエージェントがいる。Hermanは新しく作られたアプリのインデックスページを読み、そのインデックスページのスクリーンショットを見て、悪意があると思ったらフラグを立てる。そしたら、誰か（だいたい私）がそのアプリを検査して、禁止するかどうかの最終決定をする。これによって、かなりの数のアプリをスキャンして、ノイズのない悪意のないアプリをフィルタリングできる。これを「ダム」サービスでやるのは現実的じゃないし、LLMの文脈が画像とソースコードの両方を取得するのにぴったり合ってる。LLMはまた、例えばDANAがマレーシアの銀行だってことを知ってるように、かなり「オムニポテント」なんだ。私が全く知らないことだけどね。こういう面倒で時間のかかる作業をエージェントで使うのはいい方法だと思う。次は、エージェントを使って「ファジー」な統合テストを試してみるつもり。LLMがブラウザとCLIツール、UAT仕様にアクセスできて、（隔離された環境で）好きなことができるようにするんだ。それから、見つけたことや改善点を報告させるために、MCP統合を使ってチケットシステムに送る。つまり、幻覚を利用して問題を見つけるってわけ。