株式会社ずんだもん技術室AI放送局 podcast 20251008

youtube版(スライド付き) 関連リンク Google DeepMind introduces new AI agent for code security Google DeepMindは、ソフトウェアのセキュリティを自動で強化する新しいAIエージェント「CodeMender」を発表しました。この画期的なツールは、AIの力でコードの脆弱性を発見し、修正することを目指しています。 現在のソフトウェア開発では、セキュリティの脆弱性を見つけて修正する作業が非常に難しく、多くの時間と労力を必要とします。従来の自動チェックツール（「ファジング」と呼ばれる多様な入力を与えてバグを探す手法など）にも限界があり、AIによる高度な脆弱性発見技術が進化するにつれて、人間だけで全ての脆弱性に対応するのは非現実的になってきています。CodeMenderは、このセキュリティ上の大きな課題を解決するために開発されました。 CodeMenderは、大きく分けて2つのアプローチでコードセキュリティを強化します。 リアクティブ（即時修正）: 新しく見つかった脆弱性を素早く自動で修正します。 プロアクティブ（根本的改善）: 既存のコードをより安全な形に書き換え、将来の脆弱性の発生を防ぎます。例えば、特定の種類の脆弱性を根本からなくすような大規模なコード改修も行います。 このAIエージェントは、Googleの最先端AIモデルである「Gemini Deep Think」をベースにしています。そのため、人間のようにコードについて深く考え、複雑な問題を解決する能力を持っています。 CodeMenderは、以下のような強力なツールや技術を組み合わせてコードの分析と修正を行います。 高度なプログラム分析: 「静的解析」（コードを動かさずに文法や構造を調べる）、「動的解析」（コードを実際に動かして振る舞いを調べる）、「差分テスト」、「ファジング」、そして「SMTソルバー」（論理的な問題を解く技術）などを駆使し、脆弱性の根本原因や設計上の弱点を特定します。 マルチエージェントシステム: 特定の課題に特化した複数のAIエージェントを連携させることで、複雑な問題にも効率的に対応します。例えば、コードを修正した後、元の機能が損なわれていないか（「デグレード」していないか）を自動で検証するエージェントも存在します。 CodeMenderが生成したコードの変更は、自動で徹底的に検証されます。これにより、「問題の根本原因が本当に解決されているか」「機能が壊れていないか」「コーディング規約に沿っているか」など、様々な観点から修正の品質が保証されます。人間が最終確認すべきは、この検証をクリアした「質の高いパッチ」のみとなるため、開発者の負担を大幅に軽減できます。 Google DeepMindは、これまでにCodeMenderを使ってオープンソースプロジェクトに72件ものセキュリティ修正を提供してきました。中には、450万行もの大規模なコードベースへの貢献も含まれています。例えば、画像圧縮ライブラリ「libwebp」で過去に発見され、iOSのゼロクリック攻撃にも悪用されたバッファオーバーフローの脆弱性（プログラムが確保したメモリ領域を越えてデータが書き込まれる問題）に対して、「-fbounds-safety」という安全なコードアノテーション（特定の情報や設定をコードに追加する印）を適用し、将来的な同種の脆弱性を防止する対策を行っています。 現在、CodeMenderが生成する全ての修正は、人間による最終レビューを経てから公開されています。これは、修正の品質を確実に保ち、オープンソースコミュニティからのフィードバックを慎重に受け止めるためです。Google DeepMindは、今後、重要なオープンソースプロジェクトの管理者と連携を深め、得られたフィードバックを基にCodeMenderを改善していく予定です。最終的には、このCodeMenderを全てのソフトウェア開発者が利用できるツールとしてリリースし、世界中のソフトウェアのセキュリティ向上に貢献することを目指しています。 引用元: https://deepmind.google/discover/blog/introducing-codemender-an-ai-agent-for-code-security/ What Makes 5% of AI Agents Actually Work in Production? AIエージェントを実際に製品として使えるようになるのは、実はたった5%くらいしかないって知っていましたか？この記事では、その成功するAIエージェントが何をしているのか、日本の新人エンジニアさんにもわかりやすく解説してくれています。 多くの人は、AIの賢さ（モデルの性能）が大事だと思いがちですが、失敗のほとんどは、そのAIを支える「周辺システム」（コンテキスト設計、セキュリティ、メモリ管理など）がうまくできていないのが原因だそうです。 「文脈（コンテキスト）」の重要性 AIエージェントにとって、「モデルは土壌、コンテキストは種」という言葉があります。つまり、どんなに高性能なモデル（土壌）があっても、適切な「文脈情報（コンテキスト、種）」を与えなければ、良い結果は生まれないということです。 最近よく聞くRAG（Retrieval-Augmented Generation）という技術が重要ですが、ただ情報を集めるだけではダメ。必要な情報だけを厳選し、正しく整理し、検証する「高度なコンテキストエンジニアリング」が求められます。例えば、関連性の高い情報だけを選んだり（選択的コンテキストプルーニング）、データの種類や鮮度をチェックしたり、どの情報がAIの回答に影響したかを追跡できるようにしたりします。 セキュリティと信頼性の確保 本番環境でAIを使う上で、特にエンタープライズ（企業）環境では、セキュリティやアクセス権限の管理が非常に重要です。誰がどんな情報にアクセスできるか、AIの出力がどの情報源に基づいているかを追跡できる「リネージ」の確保が必須です。また、同じ質問をしても、社員の役職や権限によってAIの回答が変わるようにする仕組みも必要になります。 そして何よりも「信頼」が重要です。AIがアシスタントとして人間をサポートし、人間が最終的な判断を下す「Human-in-the-loop（人間が介入する）」設計が、ユーザーからの信頼を得る上で欠かせません。 メモリ管理と複数モデルの使い分け AIエージェントは、過去のやり取りやユーザーの好みを覚える「メモリ」を持つことで、より賢くパーソナルな体験を提供できます。しかし、そのメモリをどう管理するか（ユーザーごとに、チームごとに、組織ごとに）、またプライバシーをどう守るかは難しい課題です。 また、すべてのタスクに同じ高性能なAIモデルを使うのは効率的ではありません。簡単な質問には高速で安価なモデルを、複雑な分析には高性能なモデルを使うなど、タスクに応じて複数のモデルを賢く使い分ける「モデルオーケストレーション」の技術も進化しています。 自然言語とGUIの適切な使い分け AIエージェントと対話する際に、何でもかんでもチャット形式が良いわけではありません。例えば、BIツールのような複雑なデータ分析では、自然言語で質問するときの学習コストを減らせます。しかし、一度答えが出たら、チャートの種類を変えるなどの微調整はGUI（グラフィカルユーザーインターフェース）で行いたいものです。ユーザーのニーズに合わせて、自然言語とGUIを組み合わせた設計が重要になります。 これからのエンジニアに求められること これからのAI開発では、単にモデルの性能を追求するだけでなく、「質の高いコンテキスト」「適切なメモリ設計」「信頼性の高いオーケストレーション」「ユーザーが信頼できるUX」といった周辺要素が、AIエージェントの成功を左右する重要なポイントになります。 新人エンジニアの皆さんも、ぜひこれらの要素を意識して、これからのAI開発に取り組んでみてください。 引用元: https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually Not Another Workflow Builder LangChainチームは、これまでビジュアルワークフロービルダーの開発に積極的ではありませんでした。最近OpenAIが同様のツールを発表したことを受け、LangChainがなぜこの道を選ばなかったのか、そして今後何に注力していくのかを解説しています。 ノーコードのワークフロービルダーは、主に非技術者がAIエージェントを構築できるようにすることを目的としています。これは、技術者不足の解消や、非技術者が持つ具体的な業務知識をAIシステム開発に活かすためです。 ここで重要なのは「ワークフロー」と「エージェント」の違いです。AIエージェントは「LLMがツールを繰り返し使って目標を達成するシステム」と定義されます。 ワークフローは、決められた手順に沿って動くため「予測しやすく」安定していますが、柔軟性（自律性）は低いです。複雑な分岐処理などを「グラフ」として視覚的に表現します。 エージェントは、自律的に判断して行動するため「柔軟性」が高い反面、結果を予測しにくい側面があります。その複雑なロジックは、自然言語の「プロンプト」に抽象化されます。 どちらも目指すのは「期待通りに動く信頼性の高いシステム」を構築することです。筆者は、OpenAIのAgentKitや既存の類似ツールは、実際には「ビジュアルワークフロービルダー」であり、真の「エージェントビルダー」ではないと指摘します。 ビジュアルワークフロービルダーには、以下の課題があります。 参入障壁が高い: 非技術者にとって、ノードとエッジを使いこなすのは依然として難しく、決して簡単に使えるわけではありません。 複雑なタスクに対応しにくい: ある程度の複雑さを超えると、ノードとエッジが画面上でごちゃごちゃになり、管理が非常に困難になります。 では、どうすれば「信頼性の高いLLMシステム」を作れるのでしょうか。筆者は問題の複雑度に応じて、最適なアプローチがあると考えます。 高複雑度: 多くの分岐や並行処理が必要な複雑なシステムには、コードによるワークフロー（LangGraphなど）が最も適しています。これまでは専門知識が必要でしたが、AIによるコード生成技術の進化により、この障壁は低くなっていくでしょう。 低複雑度: 比較的シンプルな問題であれば、プロンプトとツールを組み合わせた「ノーコードエージェント」で十分な性能を発揮できるようになってきました。AIモデルの性能向上に伴い、解決できる問題の範囲はさらに広がると予想されます。 このように、ビジュアルワークフロービルダーは、シンプルな問題解決ではノーコードエージェントに、複雑な問題解決ではコードによるワークフローに、それぞれ優位性を奪われる「挟み撃ち」の状態にあると筆者は主張します。 LangChainが考える、今後注目すべき課題は以下の2点です。 ノーコードで「信頼性の高い真のエージェント」を簡単に作る方法: ビジュアルワークフローではなく、よりシンプルで効果的なエージェントの作成方法。 LLMを活用したワークフローやエージェントを生成する「コード生成AI」の性能向上: AIが自動でコードを書く能力を高め、より複雑なシステム開発のハードルを下げる。 LangChainは、既存のノーコードワークフロービルダーを評価しつつも、より本質的なAIシステムの開発手法に焦点を当てていることがわかります。 引用元: https://blog.langchain.com/not-another-workflow-builder/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

There are no comments yet.

Please log in to write the first comment.