株式会社ずんだもん技術室AI放送局 podcast 20250527
内容紹介
Infinite tool use、エディタ型からCLI型・自律型へと多様化するコーディングエージェント、LLMガードレールの活用法と役割を正しく理解する、AIに「綾波レイとブルーレイはどっちがきれい？」と聞いてみたｗｗ
出演者
関連リンク
この記事では、これからの大規模言語モデル（LLM）は、自分で文章などを直接生成するのではなく、「ツールを呼び出すこと」と「そのツールへの指示（引数）」だけを出力することに専念すべきだ、という革新的な考え方が提案されています。
なぜこのように考えるのでしょうか？それは、LLMと外部ツールがそれぞれの得意なことに特化し、協力することで、より効率的で強力なシステムを構築できるからです。ツールは、特定のタスクの状態や目標、過去の作業履歴といった「具体的な情報」や「操作」を保持し実行します。一方、LLMは、次にどのツールをどう使うか判断するために必要な「直近の情報」や「全体的な状況」だけを持つようにします。これにより、LLM自身の記憶や処理の負担を減らし、より効率的で専門的な処理を外部のプログラム（ツール）に任せることができます。
現在の多くのLLMは、指示に対してテキストを一気に生成します。この方法にはいくつかの課題があります。例えば、長い文章を作成する際に、途中で間違いを訂正したり、全体の構成を大きく変更したりするのが難しいです。人間のように、大まかなアイデアから書き始め、細部を詰め、後から自由に行き来して修正するような柔軟な作業（マルチ解像度生成）が苦手なのです。また、生成されるテキストが長くなると、LLMが保持する情報量が増えすぎてしまい、処理が難しくなる問題もあります。
ここで「ツールを使う」という考え方が力を発揮します。
LLMが文章を直接生成する代わりに、まるで人間が使うような「テキストエディタ」というツールを操作するコマンドだけを出力することを想像してください。LLMは「この段落を削除」「ここにこの文章を追加」「この部分を修正」といった指示をツールに送ります。ツールは指示通りに文章を編集し、その結果をLLMに返します。これにより、LLMは文章を途中から自由に編集したり、構成を大きく変えたりといった、人間のような試行錯誤を伴う柔軟な作業が可能になります。間違いもツール上で修正すれば、LLM自身の記憶を混乱させることもありません。
この考え方は、文章生成だけでなく、様々なタスクに応用できます。例えば、3Dモデルを作成する場合、LLMは3Dモデリング用のコードを生成・実行するツールを操作します。長い動画を理解する場合も、動画の特定部分を視聴したり、重要な情報をメモしたりするツールを使うことで、効率的に処理を進められます。
ツールを使うことで、LLMは複雑なタスクに取り組む際に、ツール上でどのような思考や操作を行ったかをより明確に表現する必要があります。これは、LLMの出力がより分かりやすくなり、意図しない挙動を防ぐといった安全性にもつながる可能性があります。
まとめると、「無限ツール使用」という新しい設計思想は、現在のLLMの限界を克服し、より複雑で大規模なタスクに柔軟に対応できる、効率的で安全なAIアシスタントを実現するための鍵となる可能性を秘めています。これを実現するには、コンテキストサイズに関わらず効率的に推論できるアーキテクチャなどが重要になると考えられています。
引用元: https://snimu.github.io/2025/05/23/infinite-tool-use.html
AIコーディングエージェントは進化し、今ではその「自律性」「動作環境」「ユーザーとの対話方法」が重要視されるようになりました。この記事では、現在のコーディングエージェントをエディタ型、CLI型、自律型の3つのタイプに分類し、それぞれの特徴やおすすめ製品、使い分けについて解説しています。
エディタ型（例: Cursor, GitHub Copilot）は、エディタ内で動作し、まるで自動運転レベル2のように、開発者が常に監視・介入しながらコード編集を行います。安全性を重視し、全ての変更を確認しながら進めたい場合に適しています。入門者向けの学習リソースが豊富で、最初に試すのに適したタイプです。Cursorやコストを抑えたいならCopilot Chat、仕組みを理解したいならRoo Codeが紹介されています。
CLI型（例: Claude Code, Codex CLI）は、ターミナル（コマンドライン）上で動作します。自動運転レベル3のように、エージェントが主体となって開発を進め、重要な判断時に開発者に確認を求めます。効率性向上を重視し、柔軟な操作や外部連携がしやすいのが特徴です。CLI型はエディタから独立しているため、エディタ型が合わなかった開発者にもおすすめです。Claude Codeは性能が高いですがコストがかかる可能性があり、Amazon Q Developer CLIは無料プランがあり低コストで試せます。仕組みを知りたい場合は、GitHub上で公開されているCodex CLIが参考になります。
自律型（例: Devin, OpenHands）は、独立した環境で、目標設定と結果確認のみでタスク完了を目指すタイプです。自動運転レベル4のように、開発者の介入を最小限にし生産性最大化を目指します。まだ実験的な段階ですが、タスク成功率が高ければ生産性を大きく向上させられます。ただし、現状はコーディング知識なしに使えるレベルではなく、適切な指示やコンテキスト準備が必要です。新技術に関心があり、検証したいアーキテクト向けと言えます。製品としては先行するDevinや、無料で利用できるJulesが挙げられています。自律型のOSSとしては、GitHubでOpenHandsが公開されています。
どのタイプにも優劣はなく、開発者の好みやタスクの内容によって適したものが異なります。新人エンジニアの方は、まず学習リソースが多いエディタ型から試してみるのがおすすめです。そして、AIコーディングエージェントの動向を追っていくことが、今後の開発に役立つでしょう。
引用元: https://blog.lai.so/agent/
近年、LLM（大規模言語モデル）を使ったアプリケーション開発が進む中で、セキュリティ対策に悩むエンジニアが増えています。その中で注目されている技術の一つが「LLMガードレール」です。これは、LLMへの入力やLLMからの出力を監視・制御する技術の総称で、例えるならWebアプリケーションにおけるWAFのような役割を果たします。
LLMガードレールには、入力に含まれる不適切な内容や悪意のある指示を検出・ブロックする「入力フィルタリング」、LLMが生成したテキストがポリシーに違反していないか、特定のトピックから逸脱していないかなどを検証・修正・ブロックする「出力内容の制御」といった機能があります。
検証によると、現代のLLMは一般的な有害コンテンツ（例えば爆弾の作り方）はフィルタリングしてくれますが、パン屋botの例のように、アプリケーション固有のルール（「提供商品リスト以外のパンを紹介しない」など）からの逸脱はLLM本体だけでは防ぎきれません。こういったドメイン固有の不適切な出力を抑えるのに、LLMガードレールによる出力制御が役立ちます。
また、プロンプトインジェクション（悪意のある指示でLLMの動作を操作する攻撃）に対して、入力ガードレールは有効な対策となり得ます。しかし、多様な攻撃手法が存在するため、ガードレールだけでは完全に防ぐことは非常に難しいのが現状です。「プロンプトインジェクションはされるものだ」と考え、LLMに不用意な機密情報を持たせないなどの対策と組み合わせることが重要です。
さらに、RAG（外部情報を参照してLLMの回答精度を向上させる技術）や、外部サービスと連携するLLMアプリケーションの場合、ガードレールはあくまで入力や出力の「テキスト内容」を検証するものです。RAGで参照する外部データベースが汚染された場合の対策や、外部連携における認可（特定の操作をしてよいか）の判断は、ガードレールだけでは困難です。これらの脅威に対しては、信頼できるデータソースのみを利用する、最小権限の原則を適用するといった根本的なセキュリティ対策が不可欠です。
結論として、LLMガードレールはLLMアプリケーションのセキュリティリスクを低減するための有用なツールですが、あくまで「緩和策」「セーフティネット」であると理解することが大切です。LLMガードレールを過信せず、アプリケーションの設計段階から基本的なセキュリティ対策（安全な設計、適切な権限管理、レートリミットなど）をしっかりと行い、その上で多層防御の一つとしてLLMガードレールを導入・活用していくことが、安全なLLMアプリケーション開発には欠かせません。
引用元: https://blog.flatt.tech/entry/llm_guardrail
AIに「綾波レイとブルーレイはどちらがきれいか？」という問いかけをしたところ、AIは「映像の美しさならブルーレイ、感情の奥行きなら綾波レイ」と回答しました。このユーモアと洞察力のある応答は、AIが単なる情報検索だけでなく、言葉遊びやニュアンスを理解して気の利いた返しができる可能性を示唆しており、AIとの対話の面白さを感じさせる一例として話題です。
引用元: https://anond.hatelabo.jp/20250526161912
（株式会社ずんだもんは架空の登場組織です）