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

youtube版(スライド付き) 関連リンク Introducing Parallel Search: the highest accuracy web search API engineered for AI 皆さん、こんにちは！今回は、AI（人工知能）開発に役立つ新しいWeb検索API、「Parallel Search」が発表されたというニュースをお届けします。特にAIエージェントを作るエンジニアさんにとっては、とても興味深い内容ですよ。 これまで主流だったWeb検索エンジンは、人間がキーワードで検索し、表示されたリンクをクリックして情報を見つけることを前提に作られていました。しかし、AIエージェントは少し違います。彼らは「何をすべきか」という意図（目的）を理解し、そのタスクを効率的に達成するための「情報（トークンと呼ばれるテキストの最小単位）」を求めているのです。AIにとって最適なのは、クリック率が高いページではなく、モデルが思考・推論するために最も関連性の高い情報が詰まった部分になります。 Parallel Search APIは、このAIのニーズに特化してゼロから設計されました。主な特徴は以下の通りです。 セマンティックな目標理解: キーワードだけでなく、AIエージェントの「目的」を深く理解して検索します。 トークン関連性ランキング: AIがreasoning（推論）しやすいように、最も関連性の高い情報（トークン）を優先的に提供します。 情報密度の高い抜粋: 長いページ全体ではなく、必要な情報が凝縮された部分を効率的に抽出してくれます。 単一呼び出しでの複雑なクエリ解決: 通常、何度も検索を繰り返さないと解決できないような複雑な質問でも、少ないAPI呼び出しで答えを見つけやすくします。 これらの工夫により、AIエージェントはより少ない検索回数で、高い精度で必要な情報を手に入れられ、結果としてAPI呼び出しのコスト削減や処理速度の向上に繋がります。 実際に様々なベンチマークテストでは、Parallel Search APIは他の既存サービスと比較して、特に複数の情報源を組み合わせたり、深い理解が必要な「複雑な検索」において、約2倍の精度と約半分のコストで優れたパフォーマンスを発揮しています。シンプルな検索でも、業界トップレベルの精度を維持しつつ、最も低いコストを実現していることが示されています。 この高い性能は、Parallel社が過去2年間で独自のWebインデックスを構築し、Webクローリングからデータのインデックス化、そしてAIに最適なランキング付けまで、検索の全工程を自社で垂直統合しているからこそ実現できたものです。 AIエージェントが「コンテキストウィンドウ」（LLMが一度に処理できる情報の範囲）に、いかに質の高い情報を取り込むかが、タスク達成の鍵となります。Parallel Search APIは、この課題を解決し、AIエージェントの能力を最大限に引き出す強力なツールとなるでしょう。もし皆さんがAIエージェントの開発に携わる機会があれば、ぜひこの新しい検索APIを試してみてはいかがでしょうか。 引用元: https://parallel.ai/blog/introducing-parallel-search ビジネス出身PMが、「AIのことはエンジニアにお任せ派」から「PMもAIエージェントを自作しよう派」になるまで この記事は、コーディング経験のないビジネス出身プロダクトマネージャー（PM）が、AIエージェント開発に挑戦し、その過程で得た実践的な学びを共有しています。 筆者が開発したのは、自社サービス「バクラク申請・経費精算」のお客様の社内運用ルールを、システムで使えるルールに自動翻訳し、AIによる申請レビューが可能か評価するAIエージェントです。これにより、お客様と社内担当者の設定作業負担を減らすことを目指しました。 このエージェントを実用的なものにするため、以下の3つの工夫を凝らしています。 「利用可能な項目」をTool（ツール）で外部から与える: LLM（大規模言語モデル）に自由にルールを生成させるのではなく、データベースの項目リストを「Tool」として提供し、その中からしか使えないように制限しました。これにより、LLMが架空の項目を作るのを防ぎ、出力の正確さを向上させています。 要所で人間がレビューを挟む（HITL: Human-in-the-Loop）: エージェントが重要な判断をする際には、必ず人間が確認・修正できるステップを組み込みました。これにより、AIの誤った解釈が進行するのを防ぎ、最終的なルールの品質を保証します。 対象ルールと動作検証済ルールの「構造」が似ているかをRAGで検索する: 「タクシー代であれば〇〇」「リムジンバス代であれば〇〇」のように、具体的な値は違ってもルールの「構造」が同じものを検出するため、ルールを変数化した上でRAG（検索拡張生成）のベクトルデータベースに登録し、構造的な類似度で検索できるようにしました。 開発を通じて、筆者は以下の重要な学びを得たと述べています。 普段使っているChatGPTのような「よしなに」動くAIは、裏で多くの「お膳立て」があって初めて実現できる。素のLLMを動かすには、その土台作りが必要。 特にビジネスで使うAIエージェントは、自由にさせるのではなく、Toolやプロンプトで適切に「制御」することで初めて価値を出せる。 AIはあくまで課題解決のための「手段」であり、AI技術そのものにこだわるのではなく、お客様への価値提供という本来の目的を冷静に評価することが重要。 非エンジニアがAIエージェントを自作するには、Pythonの基礎やAI関連ライブラリの知識など、多くのスキルが求められ、一人で完遂するのは非常に困難です。しかし、社内のエンジニアからのサポートがあれば、実践を通じてPMもAI技術への理解を深めることができます。PMとエンジニアが協力してAIを活用することで、プロダクトの価値提供スピードを加速できる、というメッセージで締めくくられています。 引用元: https://tech.layerx.co.jp/entry/2025/11/06/080000 Code execution with MCP: building more efficient AI agents この記事は、AIエージェントをより効率的に動かすための新しい技術「コード実行」について解説しています。特に、AIエージェントが外部システムと連携するための標準プロトコル「MCP（Model Context Protocol）」利用時の課題解決に焦点を当てています。 新人エンジニアの皆さん、AIエージェントはGoogle DriveやSalesforceのような様々なツールと連携して複雑なタスクをこなしますが、その連携方法には工夫が必要です。 MCPの課題：AIの情報処理負担 MCPは、AIエージェントが多くの外部ツールと効率的につながるための共通ルールです。しかし、接続するツールが増えると、AI（LLM）が処理できる情報量（コンテキストウィンドウ）に負担がかかるという問題が発生します。 ツール定義で情報過多：エージェントが使えるツールの説明が多すぎると、AIは毎回大量の情報を読み込む必要があり、処理が遅くなりコストも増えます。まるで、必要なページを探すために分厚い辞書を毎回全てめくるような状態です。 中間結果も負担に：ツールを使って得られたデータ（例：会議の議事録全文）も、AIのコンテキストウィンドウを通過するたびに情報量が増え、AIの処理負担となります。これにより、データ量が多いとエラーを起こしやすくなることもあります。 コード実行による解決策：効率的な連携 この課題を解決するのが「コード実行」というアプローチです。これは、MCPサーバーを「コードAPI（プログラムから呼び出せる機能）」として扱い、AIエージェントが自分でプログラムコードを書いてツールを操作する方法です。 このアプローチには、以下のようなメリットがあります。 必要なツールだけ読み込む：AIエージェントは、タスクに必要なツールの定義だけをオンデマンドで読み込みます。これにより、無駄な情報でコンテキストウィンドウを圧迫することがなくなり、処理速度とコストを大幅に削減できます（例：15万トークンが2千トークンへ、98.7%削減）。 効率的なデータ処理：大量のデータ（例：1万行の表データ）を処理する場合でも、AIエージェントはコードを使って必要な部分だけをフィルタリングしたり整形したりできます。AIには処理済みの少ないデータだけが渡されるため、負担が軽くなります。 複雑な処理をコードで：繰り返し処理（ループ）や条件分岐、エラー処理といった複雑なロジックも、AIが直接ツールを呼び出すよりも、コードとして書く方が効率的かつ確実に実行できます。 プライバシー保護：コード実行環境の中でデータ処理が行われるため、機密情報（個人情報など）がAIのコンテキストウィンドウに直接入ることなく、安全に扱えます。 スキルの蓄積と再利用：一度うまく書けたコードを「スキル」として保存し、将来のタスクで再利用できます。これにより、AIエージェントは徐々に高度なタスクを効率よくこなせるようになります。 考慮すべき点 ただし、AIが生成したコードを実行するには、安全な実行環境（サンドボックスなど）の準備が必要で、セキュリティや運用面でのコストも発生します。 まとめ MCPとコード実行を組み合わせることで、AIエージェントはより多くのツールを効率的・安全に使いこなし、賢くタスクをこなせるようになります。ソフトウェア開発の知恵をAIエージェントに適用する、実践的で重要な技術です。 引用元: https://www.anthropic.com/engineering/code-execution-with-mcp 夜のハンマーヘッドは…by中卒チック症ずんだもん スニーカーダンク スニーカーダンクに投稿された記事で、ユーザー名「中卒チック症ずんだもん」さんが、夜のハンマーヘッドが「くっそ寒い」とカジュアルに注意喚起しています。親しみやすいずんだもんの口調で、これからハンマーヘッドを訪れる人に「各位気を付けるように」と呼びかける内容は、新人エンジニアの方々が少し疲れた時にクスッと笑える、心温まる一言です。寒い日も油断せず、体調管理に気をつけましょう。 引用元: https://snkrdunk.com/post/958810/ お便り投稿フォーム VOICEVOX:ずんだもん

youtube版(スライド付き) 関連リンク 2025/11/04 Builders Flash にて “AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ” を公開しました freeeのAI駆動開発チームの中山さんが、AWSの公式ブログメディア「Builders Flash」に、最新のAI技術活用に関する記事を寄稿されました。タイトルは「AWS と LiteLLM で実現する、セキュアで柔軟な AI エージェント基盤のアーキテクチャ」で、2025年11月4日に公開されています。 この記事の最も大切なポイントは、AIエージェントを企業で安全かつ効率的に動かすための「プロキシ基盤」の構築方法について解説している点です。最近、ChatGPTのような大規模言語モデル（LLM）をベースにしたAIエージェントが注目されていますが、これを実際にビジネスで使うには、情報漏洩を防ぐセキュリティ対策や、費用を抑えるためのコスト管理、そしてシステムが安定して動き続けるための仕組みなど、考慮すべき点がたくさんあります。 そこで、この記事では「LiteLLM」というオープンソースライブラリが重要な役割を果たします。LiteLLMは、OpenAIやAnthropic、Googleなど、様々なLLMサービスへのアクセスを統一された方法で扱えるようにしてくれるツールです。記事では、このLiteLLMをプロキシとして利用し、AWSのサービス（例えば、計算リソースを提供するEC2やLambda、ネットワークを安全に構築するVPCなど）と組み合わせることで、次のような大きなメリットを持つAIエージェント基盤を実現できると紹介しています。 セキュリティの強化: LLMサービスへ直接アクセスするのではなく、間にプロキシを置くことで、リクエストの内容を監視したり、認証・認可を一元的に管理したりできます。これにより、機密情報の漏洩や不正な利用を防ぎ、安全性を高めることができます。 柔軟なLLMの選択と切り替え: LiteLLMは多様なLLMプロバイダに対応しているため、もし将来、より性能が良かったり、費用が安かったりする新しいLLMが登場しても、アプリケーションのコードを大きく変更することなく、簡単に切り替えることが可能です。これは、特定のベンダーに縛られず、常に最適なAIモデルを選べるという点で非常に重要です。 コストの管理と最適化: プロキシを通じてLLMへのリクエストを集中させることで、APIの利用状況を詳細にモニタリングし、不要な利用を制限（レートリミット）するなどして、コストを効率的に管理・最適化できます。 開発効率の向上: 開発者は個々のLLMプロバイダのAPI仕様を詳しく覚える必要がなく、LiteLLMという共通のインターフェースを通して開発を進められるため、開発スピードを上げることができます。 新人エンジニアの皆さんにとって、AIエージェントを「どう使うか」だけでなく、「どうやって安全に、効率よく、そして将来性を見据えてシステムを構築するか」という視点は、これからのキャリアで非常に役立つでしょう。この記事は、AIエージェントのインフラ設計や運用に興味がある方にとって、具体的なヒントと実践的な知見を与えてくれるはずです。ぜひリンク先の記事を読んで、AIエージェント基盤の奥深さを学んでみてください。 引用元: https://developers.freee.co.jp/entry/aws-builders-flash-202511 LLM APIを2年間本番運用して苦労した話 この発表は、株式会社IVRyが電話の自動応答システムでLLM APIを2年間本番運用する中で直面した課題と、それらを乗り越えるための知見を新人エンジニアにも分かりやすく解説しています。 まず、LLM APIは様々な質問に対応できる「zero-shot learner」として非常に有用で、多くのタスクに活用できると指摘されています。しかし、既存の一般的なAPIとは異なる特有の問題があることも強調されました。 運用初期には大きな問題はなかったものの、ある日発生した大規模なAzure OpenAI障害をきっかけに、「LLM APIは必ず落ちる可能性がある」という現実を痛感。これを受けて、障害発生時に別のLLMに切り替える「フォールバック」の仕組みを導入し、さらに「監視体制を強化」しました。 しかし、フォールバックだけでは解決できない新たな課題が見つかります。それは、LLMが完全に停止するわけではなく、「応答が遅くなる（レイテンシーの悪化）」や「不正確な回答を返す（精度劣化）」といった、エラーとして検知されにくい障害パターンです。これらはフォールバックが効かないため、ユーザー体験に直接影響を与えてしまいます。 これらの問題に対し、IVRyでは以下の対策を講じました。 きめ細かい監視の実施: LLMの応答速度は、利用するモデル、入力の長さ、情報の種類（モダリティ）、出力の長さなど、様々な要因で変動します。そのため、これらの要因ごとに分けて監視することで、異常を早期に発見できるようにしました。 障害パターンごとの対応手順書（Playbook）作成と訓練: どんな異常が起きたらユーザーにどのような影響があるのか、どうやって検知するのか、そしてどのようなアクションを取るべきかを事前に具体的にまとめたPlaybookを作成。さらに、実際に障害が発生したと想定して訓練を行うことで、迅速かつ適切な対応ができるようにしました。 ライブラリ選定の注意点: LLM APIの共通化やフォールバックのために便利なライブラリ（例: LiteLLM）を使っていたものの、バージョンアップで予期せぬCPU使用率の増加が発生しました。ライブラリに頼りきるのではなく、場合によっては自前で実装することも含め、コントロールが効く選択肢を検討することの重要性が示唆されました。 まとめとして、LLM APIを安定して本番運用するためには、「障害は必ず起こる」という前提に立ち、フォールバックの仕組みだけでなく、多角的な監視、具体的な対応手順の準備、そして使用する技術スタックの選定に至るまで、徹底した対策が必要であると締めくくられています。これは、これからLLMを活用したサービス開発に挑戦する新人エンジニアにとって、非常に実践的な教訓となるでしょう。 引用元: https://speakerdeck.com/ivry_presentationmaterials/llm-apiwo2nian-jian-ben-fan-yun-yong-siteku-lao-sitahua AIを賢く動かすのは「指示力」ではなく「文脈設計力」 AIを効果的に活用するためには、細かく指示を出す「指示力」だけでなく、「AIに何を見せるか」を設計する「文脈設計力（コンテキストエンジニアリング）」が非常に重要である、という内容の記事です。特に、AIコーディングでAIとのやり取りに時間がかかってしまう新人エンジニアの皆さんに、AIの特性と賢い付き合い方を分かりやすく解説しています。 なぜAIとの会話がうまくいかないことがあるのでしょうか？その理由は、大規模言語モデル（LLM）が持ついくつかの制約にあります。 LLMは確率で動いている: AIは次に続く単語を確率的に予測して生成しています。同じ指示でも結果が微妙に変わるのはこのためです。この確率の精度は「コンテキスト（文脈）」に大きく左右されます。 会話が長くなると品質が下がる（コンテキストの腐敗）: 人間と同じで、AIも一度にすべての情報に完璧に注意を払うことはできません。会話が長くなると重要な情報が埋もれたり、途中の情報を忘れやすくなる「Lost in the Middle問題」が発生します。 記憶力には限りがある（コンテキストウィンドウ）: LLMには一度に処理できる情報量に「コンテキストウィンドウ」という上限があります。この上限を超えると、AIは古い情報を忘れてしまいます。プロジェクトルール、ツール定義、会話履歴などがこのウィンドウを圧迫し、重要な情報がAIに伝わりにくくなる原因になります。 これらの制約を踏まえ、AIを賢く動かすためには、単にプロンプトを詳しく書く「足し算」のアプローチではなく、本当に必要な情報だけをAIに見せる「引き算」のアプローチ、つまり「コンテキストエンジニアリング」が不可欠です。 具体的な対処法としては、以下のようなものがあります。 会話をこまめにリセットする: タスクが変わったり、会話が行き詰まったりしたら新しいチャットを始める。 プロジェクトルールの見直し: 使わないルールや細かすぎる指示は削除する。 ツールの整理: 今のタスクで必要なツールだけを有効化する。 関係ないファイルを除外する: AIに見せる必要のないファイルは.gitignoreなどで減らす。 これらの「引き算」のアプローチを実践するには、コードの構造や問題の本質、最終的なゴールなど、基礎的な理解が求められます。コンテキストを最適化することは、AIの応答品質を高めるだけでなく、利用コストの削減やAPIのレート制限回避にも繋がるという、大きなメリットがあります。 今後、複数のAIエージェントを同時に動かすような開発スタイルが普及するにつれて、それぞれのAIに適切な文脈を渡す「文脈設計力」はますます重要になるでしょう。この考え方を身につけて、AIをもっと効率的に活用できるようになりましょう。 引用元: https://zenn.dev/aun_phonogram/articles/44d298f8d9d0fd お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク 組織全体の開発スループットを劇的に向上させた「AIプランナー」とは？ 〜Speeeが実践する3つのTipsと新しい開発チームのかたち〜 Speee社は、開発のスピード（スループット）を劇的に向上させるため、「AIプランナー」という新しい取り組みを実践しています。これは、通常エンジニアではない企画担当者（プランナー、PM、PO）がAIの力を借りて、企画から開発、リリースまでの一連のプロセスを自分たちで行う役割です。 この背景には、「簡単な修正に時間がかかる」「バグ確認やデータ取得のためにエンジニアに依頼が必要」「もっとリリースしたいがエンジニアのリソースがない」といった、開発チームが抱える課題がありました。そこで、企画者自身がアイデアを最も深く理解しているという考えのもと、AIを前提とした開発体制を築き、Issue（開発タスク）を立てた人がそのまま開発まで完結させることを目指しています。 「AIプランナー」の導入により、組織全体のリリース量は134%も増加し、プランナーによるリリースが全体の15%を占めるまでに成長しました。具体的な成果としては、高価なAI-OCRサービスの内製化によるコスト削減（10分の1）、デザイン情報からのUI自動生成、バグ修正の自己完結、Miroの仕様をAIが読める図に変換してエンジニアへの伝達をスムーズにするなどがあります。 もちろん、新しい取り組みには課題も伴いました。 環境構築の難しさ: クラウド開発環境（GitHub Codespaces）だけでは解決せず、複雑な修正ではローカル環境設定が必要なケースも。 【Tips】 簡単な修正はCodespaces、複雑な修正はローカル環境と、タスクに応じて最適な環境を使い分ける柔軟性が重要です。 AIによるUI修正の難しさ: 自然言語での指示だけでは、AIにコンポーネント構造を正確に理解させ、意図通りにUIを修正させるのは難しい。 【Tips】 AIはあくまで補助ツール。プランナー側にもコードを理解する基礎知識が求められ、失敗を繰り返しながら学習するプロセスが不可欠です。 コード品質と一時的なエンジニアの負荷増: AIが生成したコードが冗長だったり、プランナーが解決できない問題でエンジニアのレビューやサポートが必要になったりすることも。 【Tips】 短期的なエンジニアの負荷増は、プランナーが細かな修正を吸収することで、エンジニアがより本質的な開発に集中できるようになるための「投資」と捉え、長期的には組織全体の生産性向上につながると考えられています。 このプロジェクトでは、「参加者全員が最低1回リリースする」「20%の参加者が週5件以上リリースする」といった目標を設定し、毎月の「ウィンセッション」でノウハウを共有し、参加者同士が助け合える環境を構築しています。 AIプランナーたちは、「Claude Code」（ターミナルで対話しながら開発できるAIツール）と「VS Code」、「Docker Compose」（ローカル開発環境）、そして「GitHub Codespaces」（クラウド開発環境）を主なツールとして活用しています。この経験を通じて、システムへの理解が深まり、Issue作成の精度やスピードが大幅に向上したとのことです。 記事は最後に、AIが言語化されたタスクをこなす時代において、PM（プロダクトマネージャー）を含む人間に求められるのは、「まだ言葉にされていない価値や課題を見つけ、問いを立て、言語化する力」であると締めくくっています。AIを強力なパートナーとし、人間にしかできない価値創造に挑むSpeee社の実践は、AI時代における開発チームのあり方を考える上で、新人エンジニアの皆さんにとっても大きなヒントになるでしょう。 引用元: https://tech.speee.jp/entry/AIplanner Introducing IndQA OpenAIが、インドの多様な言語と文化を深く理解し、推論するAIモデルの能力を評価するための新しいベンチマーク「IndQA（インドア）」を発表しました。これは、AGI（人間のように考えて行動するAI）を世界中の誰もが活用できるようにすることを目指す、重要な一歩となります。 なぜIndQAが必要なのか？ 現在、世界の約8割の人々は英語を第一言語としていません。しかし、多くのAIモデルは英語を中心に開発され、その性能を測る既存のベンチマーク（MMMLUなど）も、主に翻訳や単純な選択問題に偏りがちでした。これでは、AIが地域の文化、歴史、日常の文脈をどれだけ理解しているかを十分に測ることができません。また、主要なベンチマークはAIモデルの進化により高得点が続出し、「飽和状態」となり、真の進歩を見極めるのが難しくなっていました。 IndQAの目的と特徴 IndQAは、これらの課題を解決するために作られました。特にインドを選んだのは、約10億人もの非英語話者がおり、22の公用語を持つ多言語・多文化国家だからです。OpenAIは、インド市場のユーザー向け製品改善にも力を入れています。 このベンチマークは、インド各地のジャーナリスト、学者、アーティストなど261名の専門家と協力して作成されました。建築、食文化、歴史、宗教、スポーツなど10の幅広い文化領域、そして英語、ヒンディー語、ベンガル語、タミル語、マラヤーラム語、さらにヒングリッシュ（ヒンディー語と英語を混ぜた話し方）を含む12の言語で、計2,278問の質問が含まれています。 IndQAの最大の特徴は、AIが簡単に答えられないような、深く文化的な知識や高度な推論を必要とする難しい問題を集めている点です。質問作成時には、当時の最新AIモデル（GPT-4oなど）が解けない問題だけを厳選する「敵対的フィルタリング」という手法が用いられました。また、各回答は、専門家が詳細に定めた評価基準（ルーブリック）に基づいて、AIモデルによって採点されます。 今後の展望 IndQAを通じて、OpenAIのAIモデルがインドの言語や文化に対してどのように理解度を向上させているかを継続的に測定していきます。このベンチマークは、どのAIが「一番優秀か」を競うためではなく、特定のAIモデルが時間と共にどのように進化するかを測るためのものです。OpenAIは、IndQAの公開が、他の言語や文化領域でも同様の新しい評価基準が生まれるきっかけとなり、より多様でグローバルなAI開発が加速することを期待しています。 新人エンジニアの皆さんにとって、このような多言語・多文化対応の評価軸は、AIが社会でより広く活用されるために非常に重要だということを理解する良い機会になるでしょう。 引用元: https://openai.com/index/introducing-indqa Circuits Updates – October 2025 Anthropicの研究チームが、LLM（大規模言語モデル）の内部メカニズムに関する最新の進捗を報告しています。特に、LLMがどのように情報を理解し、処理しているかを探る上で重要な2つの研究成果が紹介されています。 一つ目は、「異なる表現形式をまたぐ視覚的特徴の理解」についてです。 LLMが単なる文字の羅列だけでなく、ASCIIアートやSVGコードといった「絵や図形」の視覚的な情報も理解していることが示されました。例えば、「目」という概念を認識するLLMの内部的な特徴は、ASCIIアートで描かれた目、SVGコードで記述された目、そして自然言語で「目」と書かれた箇所の、すべてで活性化することが分かりました。これは、LLMが様々な表現形式を横断して、同じ意味を持つ情報を認識できる「クロスモーダル特徴」を持っていることを示しています。 また、これらの特徴は、その図形がどのような文脈に置かれているか（例えば、円が「顔」の構造の中にないと「目」として認識されない）によって活性化の仕方が変わる、文脈依存性を持つことも明らかになりました。さらに、これらの特徴を意識的に操作（「steering」と呼びます）することで、LLMが生成するテキストベースの絵（例：ASCIIアートのしかめっ面を笑顔に変える、SVGの顔にシワを加える）を、意味のある形で変更できることも実証されました。これにより、LLMが絵を認識するだけでなく、その意味を理解して生成を制御する能力を持つことが示唆されています。 二つ目は、「辞書学習モデルのデータポイント初期化」についてです。 LLMの複雑な内部をより深く理解するために使われる「辞書学習モデル（Sparse Auto-Encoder: SAE）」という解析ツールの性能を向上させる、新しい初期化手法「Data Point Initialization (DPI）」が提案されました。辞書学習モデルは、LLMが学習した多数の潜在的な特徴を効率的に抽出するのに役立ちます。DPIは、モデルの重み行列を実際のデータポイントに近い形で初期化することで、学習効率と抽出される特徴の品質を向上させます。この手法を導入することで、LLMの内部特徴をより効率的かつ正確に抽出できるようになり、モデルの「解釈可能性（interpretability）」研究、つまり「LLMがどのように考えているのか」を解き明かす研究において大きな進歩が期待されます。 これらの研究は、LLMがどのように世界を理解し、創造しているのかという、AIの最も根本的な謎を解き明かすための重要な一歩となるでしょう。 引用元: https://transformer-circuits.pub/2025/october-update/index.html#svg-cross-modal お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク How Code Execution Drives Key Risks in Agentic AI Systems AIの進化により、AIが自分でコードを生成し、それを実行して自律的に動く「AIエージェント」が注目されています。これは非常に便利な機能ですが、同時に新たなセキュリティリスクも生み出しています。新人エンジニアの皆さんも、AIシステムを扱う際には特に注意が必要です。 一番のポイントは、AIが生成したコードは「信頼できないもの」として扱うべきだということです。なぜなら、悪意のあるユーザーが巧妙な指示（プロンプト）を与えることで、AIに危険なコードを生成させ、それがシステム上で実行されてしまう可能性があるからです。これが「リモートコード実行（RCE）」のような、システムを乗っ取られるほどの深刻な脆弱性につながる可能性があります。 これまでのセキュリティ対策として、生成されたコードの中から危険な部分を検出・除去する「サニタイズ（フィルタリングや無害化）」という手法がよく使われてきました。しかし、この記事では、サニタイズだけでは不十分だと指摘しています。攻撃者は、フィルタリングをすり抜ける方法を常に探し、見つける可能性があるからです。たとえば、既存の安全なライブラリ機能を悪用したり、AIの挙動を操作したりすることで、サニタイズを回避できてしまうケースが実際に確認されています。 NVIDIAのセキュリティチームも、AIを活用した分析ツールで実際にこのような脆弱性を発見しました。この事例は、サニタイズだけでは防ぎきれない、システム全体のリスクであることを示しています。 では、どうすれば良いのでしょうか？ 記事が強調しているのは、「サンドボックス化」の導入が必須であるという点です。サンドボックスとは、AIが生成したコードを実行するための隔離された安全な環境のことです。たとえ悪質なコードが生成されても、このサンドボックス内で閉じ込めることで、システム全体への影響を最小限に抑えることができます。これは、コードがシステム全体を自由に操作するのを防ぐための「実行境界線」を設けるイメージです。 重要な教訓は以下の3点です。 AIが生成したコードは、ユーザーからの入力と同様に「信頼できないもの」と考える。 サニタイズは補助的な対策であり、それだけに頼るのは危険。 実行環境の「サンドボックス化」は、AIがコードを実行するシステムには必須のセキュリティ対策である。 AI技術を安全に活用していくためには、単にコードをフィルタリングするだけでなく、実行環境を根本的に隔離するという構造的な対策が不可欠です。AIエージェントを開発する際は、この「サンドボックス化」を設計の初期段階から考慮に入れるようにしましょう。 引用元: https://developer.nvidia.com/blog/how-code-execution-drives-key-risks-in-agentic-ai-systems/ Tongyi DeepResearch: A New Era of Open-Source AI Researchers 皆さん、最新のAI技術に触れる良い機会です！今回ご紹介するのは、Alibabaが発表したオープンソースのWebエージェント「Tongyi DeepResearch」です。これは、複雑な情報探索や問題解決を自律的に行うことができるAIで、なんとOpenAIの同様のエージェントに匹敵するほどの高性能を実現しています。GitHubでその詳細が公開されているため、私たちエンジニアが実際に触れて学ぶことができるのは大きな魅力です。 Tongyi DeepResearchは、Webブラウジングやデータ分析をこなし、人間が与えるような多様なタスクを高い精度で実行します。例えば、「Humanity’s Last Exam」という学術推論タスクや、Web上の情報を探索する「BrowseComp」といった難しいベンチマークで、これまでのAIを上回る優れた結果を出しています。 この高性能を支えるのは、独自の学習方法です。特に注目すべきは、完全に自動化された高品質な合成データ生成です。人間が介入することなく、AIがより高度な学習をするための高品質なデータを大量に作り出すことで、AIエージェントの能力を限界まで引き上げています。これにより、継続的事前学習（CPT）、教師ありファインチューニング（SFT）、そして強化学習（RL）という一連の学習プロセスが、効率的かつ安定して行われています。開発チームは、アルゴリズムだけでなく、このデータの質と学習環境の安定性が、AIエージェントの性能を決定する上で非常に重要だと強調しています。 Tongyi DeepResearchには、タスクの性質に応じて二つの動作モードがあります。 一つはシンプルな「ReActモード」。これは「思考→行動→観察」というサイクルを繰り返し、モデル本来の能力を発揮させます。もう一つは、より複雑な長時間のタスクに対応する「Heavyモード」です。このモードでは「IterResearch」という革新的なアプローチを採用しており、過去の情報を全て溜め込むのではなく、必要な情報だけを選んでタスクを「研究ラウンド」に分解します。これにより、情報過多による「認知的窒息（cognitive suffocation）」を防ぎ、AIが常にタスクに集中し、高い推論品質を維持できるよう設計されています。 すでに現実世界での応用も始まっており、Alibaba社内では地図ナビゲーションエージェント「Xiao Gao」や、法律調査を行うエージェント「Tongyi FaRui」として活躍しています。これらの例は、Tongyi DeepResearchが単なる研究成果に留まらず、具体的なビジネス課題を解決できる実用的なAIであることを示しています。 もちろん、まだ改善の余地はあります。現在の課題としては、より長いコンテキスト（文脈）を扱えるようにすること、さらに大規模な基盤モデルへの適用、強化学習の効率化などが挙げられています。 新人エンジニアの皆さんにとって、このようなオープンソースで高性能なAIエージェントの登場は、最先端の技術動向を理解し、実際にAIエージェントを構築するヒントを得る貴重な機会になるでしょう。ぜひ、GitHubリポジトリを覗いてみてください。 引用元: https://tongyi-agent.github.io/blog/introducing-tongyi-deep-research/ 【備忘録】AI駆動開発Conference Autumn 2days で 学びと気づきが得られすぎたので、共有したい… 2025年10月に開催された「AI駆動開発 Conference Autumn」での学びを、新人エンジニアの方々にも役立つようにまとめました。AIを活用した開発の最前線と実践的な知見が詰まっています。 AIとの賢い付き合い方：同僚のように協業しよう AIは「同僚エンジニア」として捉え、期待することを具体的に、そして背景情報も添えて伝えると、より質の高い結果が得られます。例えば、コードの質問をする際は「なぜこのコードについて質問するのか？」といった目的も一緒に伝えると効果的です。また、「think ultrathink」のような指示でAIの推論を深めることができ、計画作成時に特に役立ちます。AIの機能が分からなければ、AI自身に「どう使ったらいい？」と質問してみるのも良いでしょう。 開発プロセスの改善：効率と品質を高める工夫 AIにタスクを依頼する際は、進捗状況を共有するためのDBを用意したり、タスクを10分単位など細かく分割して指示したりすることで、効率的に並行開発を進められます。また、AIに実装させたコードは「さらに改善して」と繰り返し指示し、テストが通るまで修正させることで品質を高めます。TDD（テスト駆動開発）は単にテストを先に書くことではなく、テストからのフィードバックを通して「最適な設計を考え続ける」プロセスです。コード品質を測る指標は、互いに補完しあうもの（例：テスト/ソース比率とカバレッジ）を選ぶと、偏りのない良いコードになります。 組織へのAI浸透と未来のエンジニア像 AI活用を組織に広めるには、「業務理解」が最も重要です。現場の業務を深く知り、「なぜ？」を掘り下げることが成功の鍵。また、AI導入には「技術理解」「組織理解」「心理的抵抗」の3つの壁がありますが、AIを使いこなす人をロールモデルにしたり、社内勉強会を開いたりして、多くの人がAIを使える文化を作ることが大切です。 AIがコード生成を高速化する一方で、デバッグやレビューがボトルネックになることもあります。AIによる効率化は、開発フロー全体を見直す視点が必要です。最終的に人がコードを読み、そこから学ぶ習慣は忘れずに。未来のAI駆動開発では、AIはテストや改善も行い、エンジニアは「感動を生むUI/UX」「ビジネスモデルの構想」など、よりクリエイティブな領域に注力できるようになるでしょう。AIと人は、状況に応じて「伴走」と「委託」を使い分ける柔軟な関係性が求められます。 引用元: https://zenn.dev/sunagaku/articles/c5affee1871afb お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク Introducing Aardvark: OpenAI’s agentic security researcher OpenAIは、GPT-5を搭載した新しいAIエージェント「Aardvark」を発表しました。これは、ソフトウェアのセキュリティ脆弱性を自動で見つけて修正を支援する画期的なツールです。 現代のソフトウェア開発では、毎年何万もの新しい脆弱性が見つかり、開発者は常にその対策に追われています。Aardvarkは、この「防御側」が優位に立てるように設計されました。人間のセキュリティ研究者のようにコードを読み、分析し、テストを行い、ツールを駆使することで、脆弱性を大規模に特定し、対処します。 Aardvarkの主な機能は以下の通りです。 分析: リポジトリ全体のコードを分析し、プロジェクトのセキュリティ目標や設計を理解します。 コミットスキャン: 新しいコードの変更が加えられると、すぐにその変更をスキャンして脆弱性をチェックします。過去の履歴も分析できます。 検証: 見つけた可能性のある脆弱性が実際に悪用できるか、安全な隔離環境（サンドボックス）でテストして確認します。 パッチ提案: 脆弱性が確認されたら、OpenAIのCodexと連携して修正パッチを生成し、人間がレビューしてワンクリックで適用できるように提案します。 Aardvarkは、従来のセキュリティツールとは異なり、AIの推論能力を活用してコードの挙動を深く理解します。GitHubなどの開発ツールや既存のワークフローとスムーズに連携し、開発スピードを落とすことなく、具体的で役立つセキュリティ情報を提供します。セキュリティ問題だけでなく、ロジックのミスやプライバシーに関するバグなども発見できるとのことです。 すでにOpenAI内部や外部パートナーのプロジェクトで数ヶ月間稼働しており、重要な脆弱性を発見し、高い検出率を示しています。特に、オープンソースプロジェクトでは10件の脆弱性がCommon Vulnerabilities and Exposures (CVE) 識別子を取得しました。OpenAIは、一部の非商用オープンソースプロジェクトに対して、無料でスキャンを提供し、オープンソースエコシステムのセキュリティ向上にも貢献していく方針です。 ソフトウェアの脆弱性は、ビジネスや社会のインフラにとって大きなリスクとなります。Aardvarkは、コードが進化するにつれて継続的に保護を提供することで、イノベーションを妨げることなくセキュリティを強化する「防御者優先」の新しいモデルを示しています。現在はプライベートベータ版として一部のパートナーに提供されており、今後さらに広く利用できるようになる予定です。 引用元: https://openai.com/index/introducing-aardvark AI エージェント時代のリスク対策 : 認証・認可をあらためて学ぶ AIエージェントが「目的を与えれば自律的にタスクを完遂する」時代が到来し、セキュリティ、特に「認証」と「認可」の重要性が増しています。AIエージェントがあなたの代理で社内ツールや機密情報を扱うようになるため、悪意ある第三者に利用された際の被害は甚大です。そこで、「誰が」「何を」「どれだけ」実行したかを追跡できる仕組みが不可欠になります。 従来のシステムでは想定されなかったAIエージェント独自のリスクとして「意図しない過剰な権限でツールを操作してしまう可能性（Excessive agency）」があります。これは、AIがユーザーの指示を解釈し、自律的に外部ツールを呼び出すことで発生します。このリスクに対処するため、AWSのベストプラクティスであるGenerative AI Lensでも言及されています。 リスク対策をしっかり行うことで、利用状況のデータに基づいた改善、コスト管理の精度向上、監査対応の効率化、そして新しいツール導入時の安全確保といった多くのメリットが得られます。 AIエージェントに適切な権限を与えるには、「認証情報（パスワードなど）を直接渡さずに、必要な範囲だけアクセスを許可する」仕組みが必要です。これを実現するのが「OAuth（オーオース）」という技術です。OAuthでは、ユーザーが一度「このAIエージェントに、この範囲の作業を許可します」と承認すると、AIエージェントは期限付きの「アクセストークン」を使ってその範囲内でのみツールを利用できます。これにより、AIエージェントにパスワードを教える必要がなく、安全に代理作業をさせることが可能です。 Amazon Bedrock AgentCoreは、このようなAIエージェントのセキュリティ対策を効率的かつ安全に実装するためのAWSのマネージドサービスです。 AgentCore Identity：ユーザーがエージェントを使う際の認証・認可（Inbound Auth）や、エージェントが外部ツールを使う際の認可（Outbound Auth）をサポートします。Amazon Cognitoなどの既存の認証プロバイダーと連携し、必要な認証情報を代わりに取得してくれます。取得した情報は「Token Vault」に安全に保管され、再利用も可能です。 AgentCore Observability：AIエージェントの行動記録を詳細に収集し、監視できます。誰がいつ、どのようなツールを使ったか、認証が成功したか失敗したかなどを追跡できるため、不正利用の早期発見やトラブルシューティングに役立ちます。 AIエージェントの安全な社会実装には、こうしたセキュリティ対策が欠かせません。Amazon Bedrock AgentCoreを活用すれば、面倒に思える認証・認可の実装や行動記録の管理も手軽に行えるため、ぜひ積極的に取り組んでいきましょう。 引用元: https://zenn.dev/aws_japan/articles/f1a0549c8e533a 【プロンプトから生まれる映像体験】Google AI Agent Summit 25 を彩った Veo のクリエイティブ 皆さん、こんにちは！Google AI Agent Summit ‘25という、AIエージェントの最先端を紹介する大きなイベントが開催され、その中で流れる印象的な映像が、Googleの生成AIモデル「Veo（ヴェオ）」によって作られたことが紹介されました。AIがこのような大規模イベントのクリエイティブな部分、具体的には幕間映像やキービジュアルなどを手掛けているというのは、AIの進化と可能性を強く感じさせるニュースですね。 このイベントで流れた映像は、「黒猫が歌っている！」とか「カピバラがかわいすぎる！」といった感想が聞こえてきそうな、個性豊かでユーモラスな動物たちのショートクリップでした。例えば、書斎で思索にふけるフクロウ教授、市場を敏捷に駆け抜けるキツネ泥棒、日本の新幹線を操縦するウサギ車掌、雪が降る中で気持ちよさそうに温泉につかるカピバラ、流れるような手つきで寿司を握るカワウソ職人、優しい表情で絵を描くリス画家、法廷で迫力満点に主張するブルドッグ弁護士、そしてディープなブルースを歌い上げる黒猫シンガーなど、まるで夢のような「もしもの世界」が生き生きと描かれています。 これらの映像は、すべて私たちが書く「プロンプト」、つまりAIへの具体的な指示文から生み出されました。記事には、それぞれのショート動画を生成するためにAIに与えられた英語のプロンプトが紹介されています。例えば、温泉のカピバラのプロンプトは「ASMR風の超クローズアップ動画。雪が穏やかに降る中、湯気の立つ温泉にうっとり浸かるカピバラ」といったように、カメラワークから情景、音響の指定まで、非常に詳細な描写が含まれています。AIにどんな言葉で、どれだけ具体的にイメージを伝えれば、こんなにも豊かで高品質な映像が生成できるのか、その表現力と可能性に驚かされます。 新人エンジニアの皆さんにとって、AIというとデータ処理や自動化、あるいはコード生成といったイメージが強いかもしれません。しかし、今回のようにAIが想像力豊かな映像コンテンツを生み出す力を持っていることを知ると、AIが活躍する分野の広さや、クリエイティブなパートナーとしての可能性に改めて気づかされるのではないでしょうか。私たちが書くプロンプトが、AIの創造性を引き出す鍵となるという点で、「プロンプトエンジニアリング」の重要性が示されています。 今回紹介された素晴らしいクリエイティブが、どのような企画やプロンプトを経て制作されたのか、その詳しい舞台裏は後日公開される予定です。AIを活用したコンテンツ制作のノウハウを知ることは、皆さんの今後のエンジニアリングやアイデア創出のヒントになるはずです。ぜひ、今後の情報にも注目してみてください。AIがもたらす創造的な未来を、私たちエンジニアがどのように形作っていけるのか、一緒に考えていきましょう！ 引用元: https://note.com/google_gemini/n/nab6cdabcbe64 お便り投稿フォーム VOICEVOX:ずんだもん

youtube版(スライド付き) 関連リンク Introducing LangSmith’s No Code Agent Builder 皆さん、こんにちは！今回は、AI開発の最前線から、新人エンジニアの皆さんにもぜひ知ってほしい画期的なニュースをお届けします。AIエージェント開発で有名なLangChainの製品「LangSmith」から、「ノーコードAIエージェントビルダー」が発表されました。これは、プログラミングの知識がなくても、誰でも簡単にAIエージェントを作れるようになるという、すごいツールなんです！ これまでのAIエージェント開発は、コードを書く必要があり、主に開発チームが担当していました。しかし、この「LangSmith Agent Builder」を使えば、社内のあらゆる部署の人が、それぞれの仕事に役立つAIエージェントを自分で作れるようになります。例えば、毎日決まった時間にメールで会議の準備状況をまとめてくれたり、送られてきたメールの内容に応じて自動でタスクを作成したりするAIエージェントを、コードなしで設定できるようになるイメージです。 一般的なビジュアルワークフローツールとは違い、LangSmith Agent Builderでは、AI（大規模言語モデル、LLM）が自ら状況を判断し、次に何をするかを決めることができます。これにより、あらかじめ決まった流れだけでなく、もっと柔軟で賢いエージェントを作れるのが大きな特長です。 AIエージェントは、主に以下の4つの要素で構成されます。 プロンプト: エージェントが何をするべきかを指示する「脳」にあたる部分です。 ツール: エージェントが外部のサービス（Gmail、Slack、LinkedInなど）と連携するための「手足」のようなものです。 トリガー: 「メールを受け取ったら」「特定のスラックチャンネルにメッセージがあったら」といった、エージェントを起動するきっかけです。 サブエージェント: 複雑なタスクを、より小さな専門のエージェントに任せることで、管理しやすくする仕組みです。 特に、AIエージェントを作る上で一番難しいと言われる「効果的なプロンプトの作成」について、このビルダーは強力なサポートを提供します。例えば、「こんなことをしたい」と話しかけるだけで、システムが詳細な質問をしながら、適切なプロンプトを自動で生成してくれます。また、エージェントが過去のやり取りやユーザーからの修正を覚えて、次回以降に活かす「記憶機能」も備わっています。 このツールは、LangChainがこれまで培ってきたAIエージェント開発の知見（LangChainやLangGraphといったオープンソースフレームワーク）を活かして作られており、エージェントが複雑な計画を立てたり、複数のステップを踏んで問題を解決したりできる「Deep Agents」という技術が土台になっています。 つまり、この「LangSmith Agent Builder」は、AIエージェント開発のハードルを大きく下げ、より多くの人がAIの力を活用できる未来を切り開くものだと言えるでしょう。現在、プライベートプレビューのウェイティングリストを募集中なので、興味のある方はぜひチェックしてみてください。 引用元: https://blog.langchain.com/langsmith-agent-builder/ StreetReaderAI: Towards making street view accessible via context-aware multimodal AI この研究は、Google Street Viewのような没入型ストリートビュー体験を、視覚に障がいのある方々（ブラインド・ロービジョンコミュニティ）にとって、より利用しやすくするための画期的なプロジェクト「StreetReaderAI」について紹介しています。これは、マルチモーダルAIと画像認識技術を活用し、これまでのストリートビューが対応していなかったスクリーンリーダーによる画像解釈や代替テキストの提供を可能にするものです。 StreetReaderAIは、UIST’25で発表されたコンセプト実証プロトタイプで、リアルタイムの文脈認識AIとアクセスしやすいナビゲーション機能を組み合わせています。チームには視覚に障がいのある研究者も参加し、アクセシビリティを重視して設計されました。主な機能は以下の通りです。 リアルタイムAI記述: 周囲の道路、交差点、場所をAIがリアルタイムで音声説明します。 ダイナミックなAIチャット: マルチモーダルAIエージェントと会話しながら、景色や地理について質問できます。 アクセスしやすい操作: 音声コマンドやキーボードショートカットで、パノラマ画像の移動や視野の変更が可能です。 ナビゲーションは、まるでビデオゲームのように音声が主要なインターフェースとなります。キーボードの矢印キーで視点変更や移動を行い、「今、北を向いています」といった音声フィードバックを得られます。 StreetReaderAIの核となるのは、Geminiをベースにした二つのAIシステム「AI Describer」と「AI Chat」です。 AI Describerは、現在のストリートビュー画像と地理情報を組み合わせて、リアルタイムで音声記述を生成します。ナビゲーションや安全性を重視したモードと、観光情報を提供するツアーガイドモードがあります。 AI Chatは、GoogleのMultimodal Live APIを活用し、ユーザーが現在の視点や過去の視点、周辺の地理について質問できるシステムです。最大約4,000枚の画像に相当する膨大な情報を一時的に記憶する能力があり、「あのバス停はどこにあった？」といった過去の質問にも文脈を理解して応答できます。 実際に11名の視覚に障がいのあるユーザーによる評価では、StreetReaderAIは高い有用性が示され、特にAIチャットのインタラクティブ性が好評でした。既存のツールにはないアクセシビリティの進歩が強調されています。AIチャットはAI Describerの6倍も利用され、パーソナライズされた会話型クエリへの明確な好みが示されました。質問内容は、位置や距離（空間的方位）、障害物の有無（オブジェクトの存在）、一般的な説明、場所の特定が多かったです。 AIチャットの応答精度は86.3%が正確で、今後の改善点としては、ユーザーがAIの回答の真偽を見極める難しさや、AIの知識の限界を理解する点などが挙げられています。 今後の展望として、より自律的な「ジオビジュアルエージェント」の開発、完全なルートプランニングのサポート、そして空間化されたオーディオなど、より豊かなオーディオインターフェースの実現が検討されています。 StreetReaderAIはまだプロトタイプですが、没入型ストリートビュー環境をすべての人にアクセス可能にする大きな可能性を示しています。 引用元: https://research.google/blog/streetreaderai-towards-making-street-view-accessible-via-context-aware-multimodal-ai/ 「Google Gemini」がプレゼン資料の自動生成に対応–「Canvas」ツールでスライド作成が可能に GoogleのAI「Gemini」に、プレゼンテーション資料を自動で作成してくれる便利な新機能が加わりました。この機能は「Canvas」というツールを使って提供され、現在はGoogleのProアカウント向けに先行公開されていますが、近いうちには無料プランでも利用できるようになる予定です。 普段PowerPointやGoogleスライドで資料を作る際、「どんな内容にしようか」「どう見せたら伝わるだろうか」と悩むことはありませんか？Geminiの新機能を使えば、その悩みから解放されるかもしれません。使い方はとても簡単で、Geminiにプレゼンテーションのテーマを伝えたり、元になるドキュメントをアップロードしたりするだけで、テーマに合った内容と関連画像を含んだスライドセットを自動で生成してくれます。 Canvasツールは、プロンプト（指示）を入力する側と、生成されたスライドのプレビューが表示される側が左右に分かれていて、リアルタイムで結果を確認しながら調整できるのが特徴です。完成した資料は、Googleスライドにエクスポートしてさらに細かく編集したり、PDFとしてダウンロードしたり、共有リンクを作成したりできます。 記事には実際に使ってみた感想も書かれており、例えば「パスワードマネージャーの長所と短所」についてプレゼンを依頼すると、13枚のスライドが生成されたそうです。ただし、AIはまだ完璧ではなく、細かいデザインの指示が意図通りに反映されないこともあったとのこと。そのため、まずはAIに大まかな草案を作成させ、その後にGoogleスライドなどで手動でテキストやデザインを調整するという使い方が、最も効率的で現実的な活用法だと結論付けられています。 この機能は、プレゼン資料作成の初期段階でのアイデア出しや、時間のかかるドラフト作成を大きく効率化してくれる可能性があります。特に忙しいエンジニアの皆さんにとって、強力なアシスタントとして活用できるでしょう。 引用元: https://japan.zdnet.com/article/35239714/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク Develop Specialized AI Agents with New NVIDIA Nemotron Vision, RAG, and Guardrail Models タイトル: Develop Specialized AI Agents with New NVIDIA Nemotron Vision, RAG, and Guardrail Models 要約: NVIDIAは、AIエージェントの開発を加速するための新しいNemotronモデル群を発表しました。AIエージェントとは、自分で考えて計画を立て、状況に応じて行動できる自律的なAIのことです。今回の発表は、特定の業務に特化したAIエージェントを、より効率的かつ安全に構築できるようにすることを目指しています。 発表された主なモデルと、それぞれがAIエージェント開発にどう役立つかを簡単にご紹介します。 Nemotron Nano 3: これは、AIエージェントがもっと賢く、効率的に「思考」するためのモデルです。例えば、複雑な科学的な問題を解いたり、プログラミングをしたり、数学的な計算をしたり、他のツールをAIが使う際の精度を高める役割をします。MoE（Mixture-of-Experts）という特別な技術を使うことで、処理速度を速くしつつ、開発コストも抑えることができます。 Nemotron Nano 2 VL: 文書、画像、動画といったさまざまな種類の情報を理解できる「マルチモーダル」なAIエージェントを作るためのモデルです。これはAIエージェントに「目と耳」の役割を与えるようなもので、データ分析、文書の自動処理、動画の内容理解など、視覚情報とテキスト情報を組み合わせて判断するAIアシスタントの開発に役立ちます。 Nemotron Parse 1.1: 主に文書から必要な情報（テキストや表など）を正確に抽出することに特化した、コンパクトなモデルです。例えば、スキャンした書類から特定のデータを自動で抜き出すような場面で活躍し、その後の情報検索の精度向上や、AIの学習データを質の高いものにするのに役立ちます。 Nemotron RAG: AIエージェントが、最新の情報や企業内の独自のデータソースから知識を引き出して、より正確で信頼性の高い回答を生成するためのRAG（Retrieval-Augmented Generation）パイプラインを構築するのに使うモデル群です。社内マニュアルを参照して質問に答えるAIや、リアルタイムのビジネス分析を行うAIエージェントの基盤となります。 Llama 3.1 Nemotron Safety Guard: AIエージェントが意図せず不適切または有害な内容を出力しないように監視し、安全性を確保するためのモデルです。特に、多言語に対応しており、文化的な違いも考慮しながら、危険なプロンプト（指示）や応答を検出する能力を持っています。 これらのモデルに加え、NVIDIAはAIモデルの性能を評価するための「NeMo Evaluator SDK」や、AIエージェントの最適な設定を自動で見つける「NeMo Agent Toolkit」も提供し、開発者がより信頼性の高いAIエージェントを効率的かつ安全に作れるようサポートしています。 引用元: https://developer.nvidia.com/blog/develop-specialized-ai-agents-with-new-nvidia-nemotron-vision-rag-and-guardrail-models/ ClaudeCodeを使ったら手作りAWSが3日でTerraform化できた話 SREのgumamonさんが、AI Agentの一種である「ClaudeCode」を使って、既存のAWS環境をわずか3日でTerraform化できたという、実践的な事例を紹介する記事です。新人エンジニアの皆さんも、これからのインフラ管理でAIがどう役立つのか、その可能性と注意点を知る良い機会になるでしょう。 まず、Terraform（テラフォーム）とは、AWSのようなクラウドサービスのインフラ構成を「コード」として定義・管理できるようにするツールです。これにより、手作業に比べてミスの削減や繰り返し作業の効率化が期待できます。この記事では、これまで手作業で作られてきたAWS環境をTerraformのコードで管理できるように変更する「Terraform化」にClaudeCodeを活用しました。 AI Agentをインフラ管理に使う際、筆者は「AIは怒れるインターン生」という比喩を使い、その限界と注意点を指摘しています。AIは指示通りに動きますが、長い指示を覚えきれず、時には「やってはいけないこと」を提案することもあります。そのため、AIにインフラの変更を直接許可するのではなく、サンドボックス環境という隔離された場所で作業させ、権限を制限する「ガードレール」の設置が必須であると強調しています。具体的には、AWSへのアクセスは読み取り専用（ReadOnly）に限定し、Terraformの状態を管理するS3やDynamoDBへの最小限の書き込み権限のみ与えるといった工夫をしています。 実際の3日間のTerraform化プロセスでは、以下のステップを踏みました。 Day1: ClaudeCodeの導入と、プロジェクトの目的や構成をAIが理解しやすいようにプロンプト（指示文）を整備。この過程で、自分自身の既存AWS構成への理解が深まったそうです。 Day2: 既存のAWSリソースからTerraformコードを生成させ、terraform importを使ってリソースをTerraformの管理下に置きました。AIとの「ペアプログラミング」のように試行錯誤しながら、プロンプトを改善していきました。 Day3: 生成されたコードのリファクタリング（より良い形に整理すること）を行いました。AIにレビューさせて命名規則のばらつきなどを指摘してもらい、修正を進めました。プロンプトを分割することで、AIがより効率的に作業できるように改善した点もポイントです。 この取り組みを通じて、筆者は以下の大きな効果を実感しました。 圧倒的なスピード: 自力で1ヶ月かかるような作業が、試行錯誤を含めてたった3日で完了。 高い応用力: 通常のツールでは対応が難しいAWSリソースについても、ClaudeCodeはコードを生成できた。 大胆な意思決定: AIの力を借りることで、手作業では諦めていた大規模なリファクタリングにも挑戦できた。 思考の整理: AIに明確な指示を出すためにプロンプトを考える過程で、自身のインフラ構成への理解が深まった。 このように、AI Agentはインフラ管理の生産性を大きく向上させる可能性を秘めていますが、その特性を理解し、適切な権限管理や監視体制のもとで活用することが非常に重要です。AIをただ使うだけでなく、AIが働きやすい環境を人間が整えることで、より効果的な協働が生まれることを示唆する良い事例です。 引用元: https://tech-blog.rakus.co.jp/entry/20251028/ai-terraforming Doubling down on DeepAgents LangChainチームは、複雑で長期間にわたるタスクを自律的に実行できるAIエージェント「DeepAgents」のバージョン0.2リリースを発表しました。これは、AIエージェントが単発のタスクを超え、より広範な問題解決に貢献することを目指すものです。 DeepAgentsの核となるのは、計画ツール、ファイルシステムへのアクセス、サブエージェント、詳細なプロンプトという4つの要素です。これらの機能をパッケージ化したdeepagentsライブラリにより、開発者は独自のツールやプロンプトを組み合わせるだけで、高度なエージェントを効率的に構築できます。 今回の0.2リリース最大の目玉は、「Pluggable Backends（プラグ可能なバックエンド）」です。これまでのDeepAgentsは、エージェントが一時的に情報を保存する「仮想ファイルシステム」のみに限定されていました。しかし0.2からは、エージェントのファイルシステムとして、永続的なデータ保存が可能な「LangGraphストア」や「ローカルファイルシステム」など、様々な種類のストレージを自由に選べるようになりました。 この機能は、エージェントに長期記憶を持たせる上で非常に重要です。例えば、特定のディレクトリへのファイル操作をAmazon S3のようなクラウドストレージにマッピングすることで、エージェントは過去の経験や学習結果を永続的に保持し、将来のタスクに活かせるようになります。また、独自のデータベースと連携するカスタムバックエンドを作成したり、ファイル書き込みにルール（ガードレール）を設定したりする柔軟性も提供されます。 その他、0.2ではエージェントの運用効率を高める改善も複数追加されました。具体的には、大規模なツール実行結果の自動ファイル保存、会話履歴が長くなった場合の自動要約によるトークン最適化、ツール呼び出し中断時の履歴自動修正などが挙げられます。 LangChainチームは、LangChain、LangGraph、DeepAgentsという3つのオープンソースライブラリを提供しており、それぞれ異なる役割を持っています。LangGraphはワークフローとエージェントを組み合わせる「エージェントランタイム」、LangChainはエージェントのコアロジックを柔軟に構築する「エージェントフレームワーク」です。そしてDeepAgentsは、計画ツールやファイルシステムといった組み込み機能を活用し、より自律的で長期間稼働するエージェントを構築するための「エージェントハーネス」として位置づけられています。これら3つのライブラリは階層的に連携し、DeepAgentsはLangChainの上に、LangChainはLangGraphの上に構築されています。 新人エンジニアの皆さんにとって、DeepAgentsの進化は、AIエージェントがより複雑なタスクをこなし、実世界で役立つ存在になるための重要な一歩を示しています。ぜひ、これらのライブラリに触れ、未来のAIエージェント開発に挑戦してみてください。 引用元: https://blog.langchain.com/doubling-down-on-deepagents/ 車に乗ってたら同乗者が目視人力でQRコードを読みとり始め、答え合わせしたら正解しててドン引きした「人かどうかも怪しいな」 走行中の車内で、同乗者が前の車のQRコードを「目視」で解読し、そのURLを手入力するという驚きの出来事がありました。後でカメラで確認したところ、手入力したURLが正確に一致していたことが判明。通常は機械が読み取るQRコードを、補助ツールなしで人間が完璧に読み解くという、信じられないような超人的な能力が話題を呼んでいます。このエピソードは、デジタル化された情報と人間の知覚力の可能性について、思わず考えさせられる内容です。 引用元: https://togetter.com/li/2621269 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク 【Claude】Agent Skills入門 - はじめてのスキル作成 - こんにちは、新人エンジニアの皆さん！今回は、生成AIの「Claude」に新しく追加された画期的な機能、「Agent Skills」について、その概要とメリット、簡単な作り方をご紹介します。 最近、GitHub CopilotのようにAIが開発をサポートするツールが増えていますが、ClaudeのAgent Skillsは、AI自身を特定のタスクに特化させ、あなたの仕事をもっと効率的にしてくれる機能です。まるで、Claudeに新しい「専門スキル」を教えるようなイメージですね。 Agent Skillsって何がすごいの？ 機能拡張と特化: あなたのプロジェクトに合わせて、Claudeに独自の機能や知識を教え込めます。例えば、「このプロジェクトのコミットメッセージのルールはこれ！」と教えれば、それに沿ったメッセージを自動で作ってくれるようになります。 繰り返し作業の削減: 一度スキルを作れば、Claudeが必要に応じて自動で使ってくれるので、同じプロンプト（指示）を何度も入力する手間が省けます。まるで賢いアシスタントがあなたの意図を汲んで動いてくれるようなものです。 効率的な処理: たくさんのスキルを教えても、Claudeが賢く情報を管理してくれるのが大きな特徴です。必要なときにだけスキルの中身を読み込む「Progressive disclosure（段階的開示）」という仕組みのおかげで、AIが処理する情報量（コンテキスト）が肥大化せず、常にスムーズに動作します。これは、従来のAIの拡張方法との決定的な違いです。 どうやってスキルを作るの？ スキルを作るのは意外とシンプルです。 .claude/skillsフォルダの中に、スキルごとにフォルダを作成します。 その中にSKILL.mdというファイルを作成し、スキルを定義します。 SKILL.mdには、スキルの「名前」や「簡単な説明」（これはClaudeがスキルを選ぶときに使う大切な情報です！）と、具体的な「指示」や「使用例」を記述します。 Anthropics社が提供する「skill-creator」というツールを使えば、これらのファイル作成を自動で行ってくれるので、初めてでも簡単に始められます。 記事では、Semantic Versioning（バージョン管理のルール）に沿ったコミットメッセージを自動生成するスキルを作成する例が紹介されています。一度作成したスキルは、Claude Codeを再起動するだけで自動的に有効になり、「コミットしてください」といった指示に対して、Claudeが状況を判断して適切なコミットメッセージを生成してくれます。 まとめ Agent Skillsは、あなたの開発ワークフローを大きく改善する可能性を秘めた、Claudeの新しい強力な機能です。今後も機能拡張が予定されており、ますます目が離せません。ぜひ皆さんも、このAgent Skillsを活用して、より快適で効率的な開発環境を築いてみてください！ 引用元: https://tech.findy.co.jp/entry/2025/10/27/070000 LangGraph と NeMo Agent Toolkit ではじめる ReAct エージェント 近年、大規模言語モデル (LLM) の進化に伴い、LLMが自律的に意思決定し外部ツールを使って複雑なタスクをこなす「AI エージェント」が注目されています。これは、単なるテキスト生成を超え、現実世界の問題解決に役立つ可能性を秘めています。 この記事では、AI エージェントの主要な手法である「ReAct (Reasoning and Acting) エージェント」に焦点を当て、その仕組みと実装、そして開発・運用を効率化するツールキットを紹介しています。 ReAct エージェントの核となるのは、LLMが「リーズニング（推論）」と「アクション（行動）」を繰り返すプロセスです。ユーザーの指示に対し、LLMはまず次に何をすべきかを推論し、必要であれば「Tool Calling（ツール呼び出し）」機能を使って外部ツール（例：Wikipedia検索、現在時刻取得など）を選択します。Tool Callingは、LLMが最適なツールとその使い方を判断する機能で、実際のツール実行は別のプログラムが行います。この推論とツールの実行を繰り返すことで、エージェントは目標を達成し、最終的な回答を導き出します。 ReActエージェントの実装には、LLMのオーケストレーションツールであるLangChainから派生した「LangGraph」が活用されます。LangGraphの最大の特徴は、エージェントの挙動を「ノード（処理の単位）」と「エッジ（ノード間の接続）」で構成されるグラフとして構築できる点です。これにより、ループや条件分岐といった複雑なエージェントの処理フローも直感的に、かつ柔軟に設計・実装することが可能です。ノード間で情報を共有する「ステート」を使い、LLMの推論やツール実行といった各ステップをノードとして定義し、ツール使用の有無に応じて処理を分岐させる「条件付きエッジ」でReActの反復構造を表現します。 さらに、エージェントシステムの開発から運用までを一貫して支援するNVIDIAのオープンソースツールキット「NeMo Agent Toolkit」も紹介されています。エージェント開発では、様々な構成の迅速な試行、パフォーマンスの最適化、そしてシステムの状態を把握する「オブザーバビリティ（可観測性）」が重要となります。NeMo Agent Toolkitは、YAMLファイルを使ってエージェントやツール、LLMの構成を簡単に定義・実行できるのが特徴です。評価やパフォーマンスボトルネックを特定するプロファイリング機能、エージェントの思考過程やツールの利用状況を詳細にトレースできるオブザーバビリティ機能（Phoenixなどと連携）を提供し、開発者がエージェントの機能改善に集中できるよう支援します。 LangGraphによる柔軟なReActエージェントの実装と、NeMo Agent Toolkitによる効率的な開発・運用支援は、AIエージェントシステムの構築を大きく加速させます。 引用元: https://developer.nvidia.com/ja-jp/blog/practical-tutorial-on-react-langgraph-nemo-agent-toolkit/ AIエージェントはなぜ複雑なタスクを完遂できないのか？ 〜コンテキストエンジニアリング＋マルチエージェント化で解く最新研究〜 最近のAI技術、特に自律型AIエージェントは、まるで人間のように考えて行動できると期待されています。しかし、実際に複雑な指示を与えると、途中で「何をすべきだったか」を忘れてしまい、タスクを最後までやり遂げられないという困った問題が起こりがちです。これは、AIが大量の情報を処理し続ける中で、最初に与えられた指示（高レベルな計画）と、その途中で行う具体的な操作や環境からの情報（低レベルな実行やフィードバック）を、一つの「コンテキスト（文脈や記憶のようなもの）」として管理しきれなくなり、混乱してしまうことが原因です。 この問題を解決するために、「コンテキストエンジニアリング」というアプローチが注目されています。これは、AIエージェントが持つコンテキストを賢く管理する手法で、特に「Isolate Context（コンテキストの分離）」が有効だとされています。簡単に言うと、一つのAIエージェントに全てをやらせるのではなく、役割に応じて複数のAIエージェントに仕事を分担させることで、それぞれが担当するコンテキストをシンプルに保ち、効率よくタスクを進めようという考え方です。 具体的な解決策として、以下の3つの手法が紹介されています。 Plan and Act（計画と実行の分離）: これは、大まかな計画を立てる専門の「Planner（プランナー）」エージェントと、その計画に基づいて具体的な操作を実行する「Executor（エグゼキューター）」エージェントに分ける方法です。Plannerは全体のゴールを忘れずに計画を練り、Executorは目の前のタスクに集中します。これにより、AIエージェントが途中で指示を忘れることなく、複雑なタスクも高い確率で完遂できるようになります。 階層型マルチエージェント（オーケストレーター）: Plan and Actのさらに進んだ形で、全体の司令塔となる「オーケストレーター」エージェントが、大きな指示を細かなサブタスクに分解し、それを担当する複数のサブエージェントに割り振ります。オーケストレーターがサブタスクをいかに明確に指示するかが成功の鍵となりますが、うまく機能すれば非常に複雑な調査や作業も効率的に進められます。 特化型の専門家エージェントへの分解: この手法では、サブエージェントをさらに「専門家」に特化させます。例えば、「データ分析専門エージェント」や「コード生成専門エージェント」のように、特定の役割やツールに精通したエージェントを事前に用意します。これにより、エージェントは「このタスクなら、あの専門家エージェントに任せよう」と判断できるようになり、コンテキストの肥大化を防ぎつつ、よりスムーズかつ的確にタスクを処理できるようになります。 これらのマルチエージェント化を通じてコンテキストを適切に管理することで、AIエージェントは複雑な指示も忘れずに、最後までタスクをやり遂げられるようになります。今後のAIエージェント開発において、これらの手法は非常に重要な知見となるでしょう。 引用元: https://techblog.insightedge.jp/entry/multi-agent-context-engineering サイゼリヤのセルフオーダー、プログラミング初心者のアプリみたいだけど大丈夫そう…？→いや異常な要件定義の精度でUXの本質を理解している サイゼリヤのセルフオーダーシステムが、シンプルすぎてプログラミング初心者のアプリのようだ、と話題になりました。しかし、多くのエンジニアは、その見た目とは裏腹に「要件定義」と「UX（ユーザー体験）」の本質を深く理解していると評価。紙メニューとの連携、番号入力の簡便さ、スマホ性能に左右されない軽快さなど、利用者の使いやすさと店舗の回転率を最優先しています。開発・保守コストも考慮された、まさに「シンプル・イズ・ベスト」な設計だと、エンジニアの間で感心を集めています。 引用元: https://togetter.com/li/2621035 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク Claude Skills でエージェントに専門的なタスクを実行させる Anthropic社から新たに発表された「Claude Skills」は、大規模言語モデル（LLM）であるClaudeに、特定の専門的なタスクを実行させるための強力な新機能です。新人エンジニアの皆さんも、これからのAI開発で活用できる可能性を秘めています。 これまでのClaudeでは、単に指示を理解して文章を生成するだけでなく、スプレッドシート作成のような定型的な作業も可能でしたが、Skills機能を使うと、さらに複雑で具体的なタスクを自動でこなせるようになります。例えば、「ウェブページのスクリーンショットを撮ってPDFにまとめる」といった、複数のステップを伴う処理をClaude自身に実行させることができます。 Skillsの大きな特徴は、Code Execution Tool（コード実行ツール）と連携している点です。これにより、JavaScriptやPythonといったプログラミング言語で書かれたコードをClaudeがサンドボックス環境で実行できるようになります。これは、通常のチャットだけでは実現できない高度な処理をAIエージェントに任せられることを意味します。 スキルを作成する際は、SKILL.mdというMarkdownファイルが中心となります。このファイルには、スキルの名前（name）と詳細な説明（description）を記述します。特に重要なのは、Claudeがいつそのスキルを使うべきかを判断するために、nameとdescriptionがシステムプロンプトに読み込まれることです。この設計は、必要な時だけ詳細な情報を読み込むことで、AIが一度に処理できる情報量（コンテキストウィンドウ）の圧迫を防ぎ、Claudeの性能低下を防ぐ工夫がされています。もしスキルの説明が長くなる場合は、SKILL.mdの本文は簡潔にし、詳細なコード例やヘルパースクリプトは別のファイルに分けて参照することが推奨されています。 作成したスキルは、ZIPファイルに圧縮してClaudeアプリの設定画面から簡単にアップロードできます。アップロード後、チャットで具体的なタスクを指示すると、Claudeがアップロードされたスキルの中から最適なものを選び、コードを実行して作業を進めてくれます。記事の例では、ウェブページのスクリーンショットを撮り、それらをPDFに変換するスキルを作成し、実際にClaudeにそのタスクを指示しています。 この機能は、AIエージェントがより自律的に、かつ高度な作業をこなせるようになるための重要な一歩と言えるでしょう。ただし、コードを実行するという特性上、セキュリティには十分注意し、信頼できるコードのみを使用することが肝要です。Claude Skillsは、AIの可能性を広げ、エンジニアの業務効率化に貢献する新しいツールとして注目されています。 引用元: https://azukiazusa.dev/blog/claude-skills-custom-skills-for-claude/ Spec Kit で SRE AI Agent を開発する長い旅の始まり この記事は、SRE（Site Reliability Engineering）業務を自律型AIで自動化・半自動化する「SRE AI Agent」の開発プロジェクトについて、GitHubが提供する「Spec Kit」と「スペック駆動開発（SDD）」を活用する実践例を紹介しています。著者は「No human labor is no human error（人間が関わらなければ人間のミスは起きない）」をミッションに掲げ、AIによるSRE業務の自動化とSREチームの負担軽減を目指しています。 Spec KitとSDDは、従来のソフトウェア開発の考え方を大きく変えるものです。これまでは「コードが王様」で仕様は補助的な役割でしたが、SDDでは「仕様が王様」となります。詳細な仕様をAIに与えることで、AIが直接コードを生成し、実装まで一貫して支援してくれる新しい開発アプローチです。これにより、仕様と実際のコードの間に生じるギャップを減らし、開発の品質と効率を高めることを目指します。 Spec Kitを使った開発は、以下のようなステップで進みます。まず、プロジェクトの原則をAIと共に確立します。次に、技術的な詳細を避けつつ「何を（What）」作りたいのか、「なぜ（Why）」それが必要なのかという「仕様」をAIに記述させます。この際、大規模言語モデル（LLM）の特性を考慮し、一度に全て決めず、小さな部品ごとに定義し段階的に進めるのがポイントです。 仕様が決まったら、今度は「どのように（How）」実装するかという「技術実装計画」をAIに作成させます。ここではPythonのバージョンやAWSの構成など、具体的な技術要素を指定します。さらに、この計画を基に、より細かな「タスク」へとブレイクダウンします。 そして「実装」です。AIエージェントにタスクごとにコードを生成させ、一つ一つのタスクを完了させていきます。ここで重要なのは、人間が直接コードを修正しないというSDDの原則です。もしコードに修正が必要な場合は、まず「仕様」を修正し、その修正された仕様に基づいてAIに新たなタスクを作成させ、再実装を進めます。 また、Spec Kitには、仕様、計画、タスクの整合性を分析する機能や、要件の品質を保証するためのカスタムチェックリストを生成する機能もあります。これにより、開発の早い段階で問題を発見し、解決に導くことができます。 著者は、SDDとLLMの組み合わせが、開発における迷走や手戻りを減らし、システム開発の新たな選択肢の一つになると期待しています。AIの能力向上、ソフトウェアの複雑化、要件変化の高速化に対応する手段として、このアプローチが注目されています。新人エンジニアの皆さんにとって、AIが開発プロセス全体を支援する未来を垣間見ることができる、興味深い取り組みと言えるでしょう。 引用元: https://zenn.dev/ryoyoshii/articles/053ebb9b4cdc58 Why Your AI Agents Need a Todo List AIエージェントの開発で、「エージェントが途中で迷子になる」「同じことを繰り返す」「まだ終わっていないのに完了したと主張する」といった壁にぶつかったことはありませんか？これは、AIの賢さが足りないのではなく、エージェントの設計（アーキテクチャ）に問題があることが多いと、この記事は指摘しています。 解決策として提案されているのは、「タスク駆動型アーキテクチャ」です。これは、AIエージェントに私たちエンジニアが使うような「Todoリスト」を強制的に持たせるという考え方です。 なぜTodoリストが重要なのでしょうか？ 私たち人間も、漠然とした指示ではうまく動けませんよね。「これを作って」というだけでは、何から手をつけて、どこまでやれば終わりなのかが曖昧になりがちです。AIエージェントも同じで、明確なタスクリスト、それぞれのタスクの「完了基準」、そして「完了したことの検証」がなければ、効率的かつ正確に作業を進められないのです。 タスク駆動型アーキテクチャでは、具体的に次のように進めます。 明示的なTodoリスト: エージェントは、各タスクの「内容」「完了検証方法」「完了状況」を記したリストを受け取ります。 厳格な実行ループ: エージェントはリストの未完了タスクを一つずつ実行します。 証拠に基づく検証: タスクが完了したら、その証拠（例：コードが動いた証拠、ログなど）を提示し、システムがそれを検証します。 完了するまで次へ進めない: 全てのタスクが検証済みになるまで、エージェントは次のフェーズに進むことができません。これにより、未完了のまま「終わった」と主張するのを防ぎます。 このアプローチは、AIエージェントが「何をすべきか」「どこまで進んだか」を常に確認できる「外部記憶」の役割を果たし、指示が曖昧なことで起こる問題を解決します。 実際にこの仕組みを導入した経験から、以下の点が重要だと述べています。 AIの「思考の柔軟さ（温度設定）」をタスクに合わせて変える: 確実に動かすインフラ系のタスクは柔軟性を低く（例：0.0）、アイデア出しのようなクリエイティブなタスクは柔軟性を高く（例：0.5）設定します。 明確な完了基準: 「ログインページを作る」ではなく、「ユーザー名/パスワード入力欄があり、送信ボタンを押すと/api/auth/loginにリクエストを送り、JWTをコンソールに出力するログインページを作る」のように具体的に定義します。 進捗の監視: 完了率やエラー頻度などを追跡し、データに基づいて改善します。 タスクの細分化: 大きなタスクは細かく分割し、明確なステップにします。 完了には「証拠」を求める: 「終わった」と信じるのではなく、「UIが動いているスクリーンショット」や「APIレスポンスのcurl出力」などの証拠を求めます。 専門家エージェントに分ける: 全てをこなす万能エージェントではなく、「要件分析」「UI設計」「バックエンド実装」のように役割を分け、連携させることで、複雑な問題を効率的に解決します。 タスク駆動型アーキテクチャは、最新のLLMを使うこと以上に、堅牢で信頼性の高いAIエージェントを開発するための土台となります。これにより、エージェントは信頼性が高く、デバッグしやすく、ユーザーから信頼され、スケールしやすいものになります。新人エンジニアの皆さんも、AIエージェントを設計する際は、まずはこの「Todoリスト」のアプローチを検討してみてください。 引用元: https://blog.justcopy.ai/p/why-your-ai-agents-need-a-todo-list YouTubeに突如現れた「じゃんけん女子高生」…なんとアニメーターの渡辺明夫氏が描いていた！本人に当時のことを直撃してみた YouTubeで突如バズった約30年前のアーケードゲーム「じゃんけん女子高生」。その可愛いキャラクターは、人気アニメーターの渡辺明夫さんがデザインしていました。渡辺さんへのインタビューで、女子高生は初心者向けサブキャラで、実は猫や舞妓さんがメインだったこと、特徴的な鼻の穴へのこだわりなどが明かされました。当時は規制でほとんど世に出なかった幻のゲームが今注目され、「恥ずかしいが、実績を見てもらえて嬉しい」と、当時の想いを語っています。 引用元: https://www.gamespark.jp/article/2025/10/26/158774.html お便り投稿フォーム VOICEVOX:春日部つむぎ

youtube版(スライド付き) 関連リンク OpenAI acquires Software Applications Incorporated, maker of Sky 皆さん、こんにちは！今回はAI業界で注目すべきニュースがあります。ChatGPTの開発元であるOpenAIが、macOS向けのAIインターフェース「Sky」を開発しているSoftware Applications Incorporatedという企業を買収したと発表しました。新人エンジニアの皆さんにとっては、AIが今後どのように私たちの仕事や日常に深く関わってくるかを知る上で、とても重要な動向なので、ぜひチェックしてください。 SkyってどんなAIなの？ Skyは、Macのパソコン上で動作する、賢いAIアシスタントです。一般的なAIチャットボットとは少し異なり、画面に表示されている内容を理解し、さらに様々なアプリ（例えば、ドキュメント作成ソフトやカレンダーアプリなど）をあなたの指示に従って操作できるのが大きな特徴です。例えば、あなたが文書を作成している時に「この段落を要約して」と指示したり、会議の予定を口頭で伝えたりするだけで、Skyがあなたの意図を汲み取り、代わりに作業を進めてくれるイメージです。まるで、いつもあなたの作業をサポートしてくれる優秀な秘書がパソコンの中にいるようなものですね。 OpenAIが買収した理由 OpenAIは、AIの能力を単に質問に答えるだけでなく、もっと実用的に、そしてシームレスに人々の生活や仕事に役立てたいと考えています。今回のSky買収は、このビジョンを大きく加速させるための一歩です。OpenAIは、Skyが持つmacOSへの深い統合技術や、ユーザーにとって使いやすい製品を作り上げるノウハウを、自社の主力製品であるChatGPTに組み込んでいく予定です。 これにより、将来的にはChatGPTが、私たちがパソコンで行うあらゆる作業において、より自然で直感的な形でサポートしてくれるようになるでしょう。例えば、プログラミング中にコードの改善案を提示したり、プレゼンテーション資料の作成を手伝ったりと、AIが私たちの「相棒」のように機能する未来が近づいています。 このニュースが示す未来 これまでのAIは、特定のウェブサイトやアプリ内で利用されることが多かったかもしれません。しかし、今回の買収は、AIがパソコンのOSレベル、つまりシステムの根幹にまで統合され、私たちの作業をより深く、そして広範囲に支援する時代が来ることを明確に示しています。 OpenAIの担当者も「ChatGPTが単にプロンプトに反応するだけでなく、実際に物事を達成する手助けをする未来を築いている」と語っています。Skyの開発者も「AIがデスクトップ上で思考や創造を助ける」というビジョンを掲げており、両社の目指す方向性が一致しています。 この動きは、AIが私たちに代わって複雑なタスクを実行する「AIエージェント」へと進化していくことを示唆しています。私たちエンジニアも、このようなAIの進化に常にアンテナを張り、どのようにAIを活用し、そしてAIと共に新しい価値を創造していくかを考えることが、これからのキャリアにおいて非常に重要になるでしょう。 引用元: https://openai.com/index/openai-acquires-software-applications-incorporated Building the Open Agent Ecosystem Together: Introducing OpenEnv Hugging FaceとMetaは、AIエージェントの開発を加速させるため、新しいオープンなエコシステム「OpenEnv」と、そのためのコミュニティハブを共同で立ち上げました。これは、AIエージェントがより安全かつ効率的に多様なタスクを実行するための重要な取り組みです。 現代のAIエージェントは非常に賢く、多くのタスクを自律的にこなせます。しかし、実際にこれらのタスクを実行させるには、エージェントがプログラムやAPIといった「ツール」にアクセスできる必要があります。問題は、無数のツールを直接AIモデルに与えると、管理が複雑になり、セキュリティ上のリスクも高まる点です。 この課題を解決するために導入されたのが「エージェント環境（Agentic Environments）」という概念です。エージェント環境とは、AIエージェントが特定のタスクをこなすために「本当に必要なものだけ」を定義する、安全で明確なサンドボックス（隔離された実行空間）のことです。これにより、エージェントがアクセスできる範囲が明確になり、セキュリティを保ちつつ、必要なツールへのスムーズなアクセスが可能になります。トレーニングでもデプロイメントでも利用でき、エージェントの行動を予測しやすくします。 Hugging Face上に開設された「OpenEnv Hub」は、開発者がこのエージェント環境を構築したり、他の開発者と共有したり、探索したりできる場所です。OpenEnvの仕様に準拠した環境は、このハブにアップロードすることで、エージェントがその環境内でどのように振る舞うかを簡単に検証できるようになります。 この取り組みでは、「RFCs（Request for Comments）」という形でコミュニティからのフィードバックを積極的に取り入れ、環境作成のための標準的なAPIを定義しています。これにより、エージェントの強化学習（RL）のトレーニング、最新の研究成果の再現、そして開発から本番環境へのデプロイまで、一貫したエージェント開発のパイプラインを構築できるようになります。 OpenEnvは、MetaのTorchForge RLライブラリをはじめ、TRLやSkyRLなどの他のオープンソースRLプロジェクトとも連携を強化していく予定です。このオープンな協力体制を通じて、AIエージェントの開発がよりアクセスしやすく、スケールしやすいものになることを目指しています。新人エンジニアの皆さんも、ぜひこの新しいオープンなエコシステムに注目し、未来のエージェント開発に参加してみてはいかがでしょうか。 引用元: https://huggingface.co/blog/openenv 【Copilot最新機能】Excelの日常業務はこう変わる、一線を越えた「Agent Mode」の衝撃 Microsoft 365 Copilotに、仕事のやり方を大きく変える二つの新機能「Agent Mode」と「Office Agent」が登場しました。これは、AIが単なるアシスタントの役割を超え、より自律的に業務を遂行する「Agent（エージェント）」へと進化することを意味します。特に、この進化によってExcelやWordといった日常的に使うツールの操作方法が、「手順を覚える」ことから「目的を伝える」ことへと大きくシフトします。 新しい働き方は「Vibe Working」と名付けられ、AIとの対話を通じて、より効率的に仕事を進めることを目指しています。 具体的な新機能は以下の通りです。 Agent Mode: ExcelやWordに組み込まれる機能で、ユーザーが「何をしたいか」を伝えるだけで、AIがそのタスクを計画・実行・検証・修正まで自律的に行います。例えば、Excelでのデータ整理や分析など、複数ステップにわたる複雑な作業も、AIが代行してくれるようになります。これにより、私たちが一つ一つの手順を細かく指示する必要がなくなり、より本質的な業務に集中できるようになります。 Office Agent: Copilotチャットを通じて、WordやPowerPointのドキュメント作成をAIに一任できる機能です。Webでの情報収集から、資料の構成案作成、デザイン、そして品質チェックに至るまで、一連の作業をAIがワンストップでこなします。 技術的な側面では、「Office Agent」にAnthropic社の高性能AIモデル「Claude」が採用され、CopilotはOpenAIのモデルを継続利用するという「マルチモデル戦略」が始動しました。これは、用途に応じて最適なAIモデルを使い分けることで、より高品質な成果を生み出すことを目指しています。 新人エンジニアの皆さんにとって、これらの機能は日常業務の生産性を劇的に向上させる大きなチャンスです。AIが自律的に動くようになることで、私たちは「どう操作するか」よりも「AIに何をさせたいか」という“問いかけの力”が重要になります。新しい技術の動向にアンテナを張り、AIを強力なパートナーとして活用するスキルを身につけることが、これからのエンジニアにとって不可欠となるでしょう。 引用元: https://www.sbbit.jp/article/cont1/173554 ポムポムプリン公式アカウントの“おさわりマップ”公開がきっかけとなり飼っている犬や猫のおさわりマップ投稿が大流行、見た目とのギャップがかわいらしい ポムポムプリン公式が公開した「おさわりマップ」がきっかけで、X（旧Twitter）では飼っている犬や猫の「おさわりマップ」を投稿するブームが起きています。これは、ペットのどこを触ると喜ぶか、どこが嫌かなどをイラストでまとめたもの。全身ウェルカムな子や、特定の場所だけを許す子など、見た目と性格のギャップが面白く、動物たちの個性豊かな反応に多くの人が癒やされ、心温まる交流を楽しんでいます。 引用元: https://togetter.com/li/2619204 お便り投稿フォーム VOICEVOX:ずんだもん

youtube版(スライド付き) 関連リンク Introducing ChatGPT Atlas OpenAIは、ChatGPTをウェブブラウザの中心に据えた新しいツール「ChatGPT Atlas」を発表しました。これは、AIを活用してインターネットの利用体験を根本的に見直し、あなたの強力な「スーパーアシスタント」として機能することを目指しています。 Atlasの主な特徴は、ChatGPTがウェブページの内容をリアルタイムで理解し、あなたの作業を直接サポートしてくれる点です。例えば、オンライン上の資料を見ながら疑問が生じた際に、その場でChatGPTに質問でき、コピー＆ペーストの手間なく回答を得られます。 さらに、「ブラウザ記憶（Browser memories）」という機能により、あなたが以前閲覧したウェブページの情報をChatGPTが記憶し、それを踏まえた上で質問に答えたり、タスクを処理したりできます。「先週見た求人情報をすべてまとめて、面接対策用の業界トレンドの要約を作成してほしい」といった高度な依頼にも対応可能です。この記憶機能は任意で、ユーザーがいつでも内容を確認・管理・削除できるため、プライバシーは確保されています。 もう一つの重要な機能は「エージェントモード」です。これは、ChatGPTがあなたの指示に基づいてウェブ上で具体的なアクションを実行してくれるものです。例えば、レシピを伝えればオンラインストアで必要な食材を検索し、注文まで代行できます。ビジネスシーンでは、チーム資料の分析や競合調査、その結果の要約なども自動で行えます。このエージェントモードは、現在Plus、Pro、Businessユーザー向けにプレビュー提供中です。 OpenAIはプライバシーとセキュリティにも力を入れています。Atlasでは、ChatGPTがアクセスできる情報や記憶する内容をユーザーが細かく設定できます。シークレットモードや、特定のサイトでChatGPTのページ内容へのアクセスを制限する機能も備わっています。また、あなたの閲覧情報がChatGPTのモデル学習に使われることは、あなたが明示的に許可しない限りありません。エージェント機能についても、コード実行やファイルのダウンロードはできないよう設計されており、金融機関のような機密性の高いサイトでは、アクション実行前にユーザーの確認を求めるなど、安全対策が施されています。ただし、AIエージェントの利用には、誤作動や悪意ある指示によるリスクも存在するため、注意して利用することが推奨されています。 ChatGPT AtlasはmacOS向けに本日より提供が開始され、Windows、iOS、Android版も近日中にリリース予定です。この新しいブラウザは、AIが日々のウェブ利用をより効率的でパーソナルなものに変え、私たちの生産性を向上させる未来への大きな一歩となるでしょう。 引用元: https://openai.com/index/introducing-chatgpt-atlas Create Your Own Bash Computer Use Agent with NVIDIA Nemotron in One Hour この記事では、NVIDIAの高性能な小型AIモデル「Nemotron Nano v2」を使って、自然言語でBashコマンドを操作できるAIエージェントを、わずか1時間、約200行のPythonコードで作成する方法が紹介されています。新人エンジニアの皆さんにとって、AIエージェント開発の第一歩として非常にわかりやすい内容です。 従来のチャットボットが質問応答に特化しているのに対し、AIエージェントは「ツール呼び出し」という機能を使って、高レベルな目標を自律的に判断し、計画し、タスクを実行します。今回のエージェントは、皆さんが普段使っているBashターミナルを「ツール」として利用し、「システム情報をまとめて」といった指示に対して、適切なコマンド（mkdir, df, free, catなど）を自動で実行し、結果を要約してくれます。 このエージェントを開発する上で重要なポイントがいくつかあります。 Bashの操作: エージェントがBashコマンドを実行し、その結果を受け取るための仕組みが必要です。作業ディレクトリの管理も大切です。 コマンドの安全性: 誤って危険なコマンドを実行しないよう、「許可されたコマンドリスト」を設定し、実行前にはユーザーの承認を求める「ヒューマン・イン・ザ・ループ」の仕組みを取り入れます。これにより、安全にエージェントを試すことができます。 エラーハンドリング: コマンド実行時のエラー（間違ったコマンド、ファイルがないなど）をAIが理解し、次の行動を適切に判断できるようにする仕組みが重要です。 システムは主に2つの要素で構成されます。 Bashクラス: Pythonのsubprocessモジュールを利用し、実際にシェルコマンドを実行する部分です。許可コマンドリストのチェックや、現在の作業ディレクトリの管理も行います。 エージェント本体: Nemotronモデルがユーザーの指示を理解し、次にどのようなBashコマンドを実行すべきか判断します。「システムプロンプト」というAIへの指示書を使って、エージェントの役割や、使えるコマンド、安全に関するルールを細かく設定します。 記事では、これらのコンポーネントをゼロから構築する方法と、LangChainのライブラリである「LangGraph」を使うことで、さらにシンプルにエージェントループを構築できる方法が示されています。LangGraphを使えば、AIエージェントの複雑な状態管理やツール呼び出しの処理を簡単に実装できます。 このチュートリアルを通して、AIエージェントがどのようにユーザーの意図を理解し、外部ツール（Bash）と連携してタスクを自律的に実行するかの基本原理を学ぶことができます。ぜひ、ご自身でコマンドを追加したり、プロンプトを調整したりして、AIエージェントの可能性を探ってみてください。 引用元: https://developer.nvidia.com/blog/create-your-own-bash-computer-use-agent-with-nvidia-nemotron-in-one-hour/ 開発合宿で Claude Codeの「サブエージェント」について学んだ話 この記事では、株式会社カミナシのエンジニアが開発合宿で学んだ、Claude Codeの「サブエージェント」という機能について、新人エンジニアの方にも分かりやすく解説されています。AIを使った開発を進める上でのヒントが得られる内容です。 開発合宿では、「人間は一切コードを書かず、AIエージェントのみでシステムを開発する」という目標が設定されました。普段のAIコーディングでは、AIに適切な指示や背景情報（これを「コンテキスト」と呼びます）を与えることがとても重要です。著者のチームでは、開発ルールをまとめた「CLAUDE.md」というファイルを使ってAIに指示を出していましたが、複数のプロジェクトを一つのリポジトリで管理する「モノレポ」環境のため、このファイルがどんどん肥大化していくという課題に直面していました。 CLAUDE.mdが大きくなりすぎると、例えばAPI開発をAIに依頼したいのに、フロントエンドのコンポーネント命名規則など、API開発には不要な情報までAIに読み込ませてしまうことになります。これはAIが指示を理解するのを難しくし、開発の効率を下げてしまう可能性がありました。 この課題を解決するために、合宿でチームメンバーから教えてもらったのが「サブエージェント」という機能です。サブエージェントとは、特定のタスク（例：フロントエンド開発、API開発、データベース設計など）に必要な情報とルールだけを持たせることができる、専門特化したAIエージェントのことです。 サブエージェントを使うことで、肥大化していたCLAUDE.mdを分割し、例えばAPI開発用のサブエージェントには「TypeScriptを使う」「関数型プログラミングで実装する」「テスト駆動開発を徹底する」といった、API開発に特化した最小限のルールだけを伝えることができるようになりました。 開発合宿では、システムアーキテクチャ設計用、API開発用、フロントエンド開発用、データベース設計用など、それぞれの専門サブエージェントを作成し、実際に開発を行いました。各エージェントには、その役割に合わせたベストプラクティスや開発ルールを「プロンプト」（AIへの指示文）として学習させました。 この仕組みを取り入れた結果、メインのCLAUDE.mdはシンプルに保たれ、各タスクを専門知識を持つサブエージェントに任せることで、AIコーディングの指示出しが非常にスムーズになり、開発の効率と精度が大きく向上したとのことです。 この記事は、「AIに『すべて』を教え込むのではなく、『必要な時に、必要な情報だけ』を渡すことが、AIを使った開発を成功させる鍵である」という重要なメッセージを伝えています。AIを活用して効率的に開発を進めるための、具体的な実践例として、新人エンジニアの皆さんにも非常に参考になるでしょう。 引用元: https://kaminashi-developer.hatenablog.jp/entry/dev-camp-claude-subagents お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク やさしいClaude Skills入門 Anthropic社のAI「Claude」に、新たに「Claude Skills」という強力な機能が加わりました。これは、Claudeが特定のタスクを高品質かつ効率的に実行するための「ベストプラクティス集」のようなもので、指示やスクリプト、必要なリソースなどを一まとめにしたものです。技術的には「Agent Skills」とも呼ばれ、最近エンジニア界隈で大きな注目を集めています。 Claude Skillsの導入で嬉しいのは、AIにタスクを依頼する際の試行錯誤が減り、まるで経験豊富な先輩が手本を示すように、Claudeが最適な手順で作業を進められるようになる点です。これにより、私たちはAIの能力を最大限に引き出し、より少ない労力で高い成果を期待できるようになります。 その仕組みは、主に「SKILL.md」ファイルに記述されたスキルの概要情報（メタデータ）と、Claudeがファイルを読み込むための「Readツール」で動きます。Claudeは必要なSkillsのファイルだけを動的に読み込むため、AIが一度に扱える情報量（コンテキストウィンドウ）を無駄に消費せず、効率的な処理を実現します。これは、常にプロジェクト全体の指示を保持する「CLAUDE.md」や、ツール接続のプロトコルである「MCP」とは異なり、特定のタスクに特化した「便利機能パック」として、より具体的な作業効率化を目指しています。 Claude Skillsは、Claude Desktop、Claude API、Claude Codeなど様々な環境で利用可能です。Desktop版では設定から簡単に有効化でき、自作のSkillsもアップロードできます。API経由の場合は事前に登録が必要です。また、公式から提供されている「skill creator」というSkillsを使えば、独自のSkillsを効率的に作成できます。 効果的なSkillsを作るための「ベストプラクティス」（良いやり方）も紹介されています。特に、SKILL.mdのメタデータは常に読み込まれるため、簡潔にまとめることが重要です。また、SKILL.md自体の内容は500行以下に抑え、詳細な情報は別ファイルに分割するのが推奨されています。 具体的な活用事例としては、ウェブサービス「キミガタリ」の月間アップデートレポートを自動作成する取り組みが紹介されています。これまでは手動で行っていた定型レポート作成作業が、Claude Skillsを使うことで、現在時刻の確認から、Qiita投稿やGitコミット履歴の取得・分析、既存フォーマットへの沿った記事作成までを自動化。数秒で「まるで自分が書いたような記事」が完成するようになり、大幅な効率化が実現しました。 Claude Skillsは、ベテランエンジニアの知識やノウハウをAIに学習させ、組織における「属人化」（特定の個人にしかできない仕事）を解消する可能性を秘めています。質の高いSkillsが販売されるエコシステムの発展も期待されており、新人エンジニアの皆さんにとって、AIの活用範囲を広げる強力なツールとなるでしょう。 引用元: https://www.docswell.com/s/harinezumi/5M683X-2025-10-21-003933 LangChain raises $125M to build the platform for agent engineering AIエージェント開発をリードするLangChainが、1.25億ドル（約180億円）の資金調達と、企業価値12.5億ドル（約1800億円）への評価を発表しました。この資金は、AIエージェントをより信頼性高く開発するための「エージェントエンジニアリング」プラットフォームの構築に充てられます。 LLM（大規模言語モデル）の登場で様々なアプリケーションが可能になりましたが、データやAPIと連携して自律的に動く「AIエージェント」こそがその真の力を引き出します。しかし、AIエージェントは試作は容易でも、本番環境で安定稼働させるのは非常に難しいという課題があります。「エージェントエンジニアリング」とは、この課題を解決し、非決定論的なLLMシステムを信頼性の高い体験へと磨き上げていく反復的なプロセスです。 LangChainはこの「エージェントエンジニアリング」のための包括的なプラットフォームを提供しています。主な発表内容は以下の通りです。 LangChainとLangGraphの1.0リリース: AIエージェントを迅速に構築できるオープンソースフレームワークが安定版となり、一般的なエージェントパターン向けのアーキテクチャが強化されました。LangGraphを使えば、エージェントの動作をより細かく制御できます。 LangSmithの機能強化: エージェントの挙動を可視化する「Observability」、生産データでテスト・評価する「Evaluation」、ワンクリックでデプロイできる「Deployment」、そしてノーコードでエージェントを構築できる「Agent Builder」（プライベートプレビュー中）が提供され、開発から運用までをトータルでサポートします。 Insights Agentの導入: LangSmithの機能として、エージェントの動作パターンを自動で分類する「Insights Agent」が追加されました。 LangChainのツール群は、AIエージェント開発のハードルを下げ、開発者が信頼性の高いエージェントをより効率的に生み出すことを支援します。AIエージェントが次の大きな波となる中で、LangChainの動向は今後も注目されそうです。 引用元: https://blog.langchain.com/series-b/ LLMs Can Get Brain Rot この研究では、大規模言語モデル（LLM）も人間のように、低品質な情報に触れ続けることで能力が低下する「LLMブレインロット（脳の腐敗）仮説」を提唱し、その実証実験を行いました。「ブレインロット」とは、インターネット上の「つまらないけれど目を引くコンテンツ」ばかりを見ていると、人間の集中力や記憶力、判断力が鈍るという俗語から着想を得た言葉です。 研究チームは、LLMが継続的に「ジャンクデータ」に触れると、モデルの認知能力が長期的に低下するという仮説を立てました。これを検証するため、実際のTwitter/Xの投稿を基に、以下の2種類の基準で「ジャンクデータ」と「コントロールデータ（通常の高品質なデータ）」を作成しました。 M1 (エンゲージメント度)：人気があって短い、いわゆる「バズった」投稿をジャンクデータとしました。これは、注意を引くが内容の浅い情報が、人間がSNSを延々と見てしまう現象に似ているためです。 M2 (意味的品質)：「すごい！」「今日だけ！」のような扇情的な言葉や誇張された表現を含む投稿をジャンクデータとしました。 これらのジャンクデータをLLMに継続的に学習させたところ、驚くべき結果が明らかになりました。ジャンクデータに触れ続けたLLMは、そうでないモデルと比べて、推論能力、長文の理解力、安全性（不適切な指示への対応）が著しく低下することが判明しました。例えば、推論タスクのスコアが大幅に落ち込んだり、サイコパシーや自己愛といった「ダークな特性」を示す傾向が強まったりしました。また、ジャンクデータの割合が増えるほど、能力の低下がより顕著になるという「用量反応性」も確認されました。 エラーの原因を詳しく調べた結果、LLMが思考プロセスを途中で省略してしまう「思考スキップ」が、能力低下の主要な要因であることが分かりました。さらに懸念されるのは、一度ジャンクデータに汚染されて能力が低下したLLMは、その後、高品質なデータを使った追加学習やファインチューニングを行っても、元の能力レベルまで完全に回復することは難しいという点です。これは、モデル内部の表現に根本的な変化が生じてしまうことを示唆しています。 この研究は、LLMの学習データとしてインターネット上の情報を用いる際、そのデータ品質の重要性を改めて浮き彫りにしました。私たちがAIの信頼性や性能を維持していくためには、継続的な学習におけるデータの選定と品質管理が極めて重要であり、まるで人間の健康診断のように、展開されているLLMに対しても定期的な「認知的健康診断」が必要であると結論付けています。 引用元: https://llm-brain-rot.github.io/ 「ひかれるという感情が薄い」→北海道の車道で目撃……車をまったく気にしない野生動物　釧路では「まれによくある」光景に5.2万“いいね” 北海道釧路で、車道をまったく気にせず堂々と歩く野生動物の姿がSNSで5.2万いいねを集め話題になっています。この地域では動物たちが車に「ひかれる」という感情が薄く、このような光景は「まれによくある」とのこと。私たちエンジニアも、時にはコードから離れて、自然の中での面白い出来事に目を向け、クスッと笑ってリフレッシュするのも良いかもしれませんね。 引用元: https://hint-pot.jp/archives/281691/3/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク Build an AI Agent to Analyze IT Tickets with NVIDIA Nemotron 現代のIT運用では、インシデントや問い合わせから生まれる膨大なチケットデータがあります。しかし、これらのデータは単なる記録であり、そこからシステム全体の課題やチームのパフォーマンスに関する深い洞察を得るのは困難です。多くの場合、手作業での分析や複雑なクエリが必要となり、時間と労力がかかります。 NVIDIAのIT部門が開発したAIエージェント「ITelligence」は、この課題を解決するために作られました。このシステムは、NVIDIA Nemotronという先進的なAIモデルの推論能力と、データ間の関係性を明確にするグラフデータベースを組み合わせています。これにより、LLM（大規模言語モデル）で非構造化データから文脈を読み解き、グラフクエリでチケット間の関係性、異常、パターンを効率的に見つけ出すことを目指します。 AIエージェントの構築は、以下の主要なステップで行われます。 データ取り込みとグラフモデリング: ITSM（ITサービス管理）プラットフォームなどからチケットデータを収集し、ユーザー、インシデント、デバイスといった情報を「ノード」、関連性を「エッジ」としてグラフデータベースに格納。複雑なデータ間のつながりを可視化し、効率的なクエリを可能にします。 文脈のエンリッチメント: チケットに「新入社員の有無」「デバイスの種類」といった補助情報を追加し、分析の分類能力を高めます。 根本原因分析（RCA）: LLM（例: Llama 3）を使って、チケットの記述や解決メモから、具体的な根本原因キーワードを自動抽出。従来のカテゴリー分類では捉えきれない詳細な問題点を特定できます。 洞察の生成: LLMが、解決時間（MTTR）、顧客満足度（CSAT）、頻繁に発生する根本原因、新入社員のオンボーディング時の課題など、組織やチームレベルでのパターンや洞察を自動生成します。 アラートと自動配信: KPIトレンドを監視し、異常があれば担当者に自動でアラートを送信。また、AIが生成した要約レポートを定期的に自動配信し、部門ごとの具体的な情報共有と意思決定をサポートします。 インターフェースには、複雑な質問に対応できるインタラクティブなダッシュボード（Grafanaなど）が採用されました。RAG（検索拡張生成）ベースのチャットボットではなくダッシュボードを選んだのは、チャットボットではユーザーの複雑な意図を正確に解釈し、常に適切なクエリを生成するのが難しい場合があるためです。代わりに、ダッシュボードのフィルタリング結果と連携するカスタムの要約サービスAPIを介して、LLMがオンデマンドで要約を生成。これにより、手動でのチケットレビューを省き、共通の問題点や推奨事項を迅速に把握できるようになります。 このAIエージェントは、非構造化されたITチケットデータを実用的な洞察に変え、IT運用の意思決定と効率化を強力に支援します。 引用元: https://developer.nvidia.com/blog/build-an-ai-agent-to-analyze-it-tickets-with-nvidia-nemotron/ Scaling Large MoE Models with Wide Expert Parallelism on NVL72 Rack Scale Systems 最近のAI、特に大規模言語モデル（LLM）はますます巨大化しており、その中でも「MoE（Mixture-of-Experts）」という特殊な構造を持つモデルが注目されています。MoEモデルは、トークンごとに一部の「エキスパート」（専門家）だけを動かすことで、従来のモデルよりも効率的に計算できるのが特徴です。しかし、このMoEモデルを非常に大規模な環境で効率よく動かすには、いくつかの課題があります。 この記事では、NVIDIAが提案する「Wide Expert Parallelism（Wide-EP）」という技術と、その基盤となる「GB200 NVL72」というシステムが、これらの課題をどのように解決し、大規模MoEモデルの推論を高速化・効率化するのかを解説しています。 MoEモデルスケーリングの課題とWide-EPによる解決策 メモリと計算のボトルネック： MoEモデルでは、必要なエキスパートの「重み」（モデルの知識データ）をGPUに読み込む作業が頻繁に発生し、これが処理の遅延につながります。Wide-EPでは、エキスパートの処理を多数のGPUに分散させることで、1つのGPUが持つエキスパートの数を減らし、重みデータの読み込みを効率化します。これにより、GPUがより集中して計算に専念できるようになります。 GPU間の通信オーバーヘッド： エキスパートが複数のGPUに分散しているため、計算結果を集約する際に大量のデータ通信が必要になります。この通信が遅れると、全体の処理速度が低下します。GB200 NVL72システムは、超高速なNVLinkという技術でGPU間を接続しており、最大130TB/秒という圧倒的な帯域幅で、この通信のボトルネックを解消します。また、NVIDIAのNCCLライブラリが最適化された通信カーネルを提供し、効率的なデータ交換を可能にします。 負荷の偏り（ロードバランシング）： 特定のエキスパートが頻繁に使われる一方で、使われないエキスパートもあるため、一部のGPUばかりが忙しくなり、他のGPUが遊んでしまうことがあります。Wide-EPの「Expert Parallel Load Balancer (EPLB)」は、利用状況に応じてエキスパートのGPUへの割り当てをリアルタイムまたは事前に調整し、すべてのGPUが均等に働くように負荷を分散します。 これらの技術はNVIDIAのTensorRT-LLMに組み込まれており、さらに「NVIDIA Dynamo」と組み合わせることで、大規模なMoEモデル推論のオーケストレーション（全体の管理）と実行を最適化します。 性能と経済性へのインパクト Wide-EPをGB200 NVL72システムで活用することで、GPUあたりの処理能力が最大1.8倍向上することが確認されています。これは、モデルの推論コスト（TCO）を大幅に削減し、より多くのユーザーに対して高速なAIサービスを提供できることを意味します。新人エンジニアの皆さんにとっては、将来、巨大なAIモデルを扱う際に、このような分散処理と最適化技術が非常に重要になるということを理解する上で、この記事は良い学びになるでしょう。 引用元: https://developer.nvidia.com/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/ AWSで障害–PerplexityやSlackなどグローバルサービスに支障 新人エンジニアの皆さん、今日の重要なITニュースについてお話しします。私たちが毎日使っているインターネットサービスは、巨大な「クラウドサービス」という基盤の上で動いていることが多いのですが、その代表格であるAmazonの「Amazon Web Services（AWS）」で、世界的な障害が発生しました。 AWSは、世界中の企業がウェブサイト、アプリケーション、データ保存、そして最近ではAIの複雑な計算処理など、様々なITシステムを動かすために利用している巨大なデータセンターの集合体です。今回の障害は、2025年10月20日17時30分頃、主にアメリカ東部の「US-EAST-1」というリージョン（物理的に離れた地域に設置された、独立したデータセンターのグループ）で発生しました。このUS-EAST-1は、AWSの中でも特に多くのサービスが利用する中心的なリージョンの一つであるため、ここで問題が起きると影響が非常に広範囲に及ぶのが特徴です。 具体的に影響を受けたサービスとしては、最新のAIチャットサービスである「Perplexity」や、多くの企業で使われているビジネスチャットツールの「Slack」の一部機能（例えば、音声会議機能のハドルなど）、ゲームプラットフォームの「EpicGames」などが挙げられています。これらのサービスが一時的に利用できなくなったり、動作が遅くなったりする事態が発生しました。この影響はアメリカだけでなく、日本のユーザーにも波及し、SNS上では「仕事で使っているSlackのハドルが使えなくて困った」「Perplexityで調べ物ができない」といった声が多数上がりました。 PerplexityのCEO、アラヴィンド・スリニヴァス氏も、自身のX（旧Twitter）アカウントで「Perplexityが現在ダウンしており、原因はAWS側の問題だ」とコメントし、復旧に向けて対応中であることを明らかにしました。AWS側も、ステータスページで問題が発生していることを公表し、原因の特定と復旧作業を進めている状況です。 今回のAWS障害は、普段当たり前のように利用しているインターネットサービスが、いかに一つの巨大なインフラに依存しているか、そして、そのインフラで障害が発生すると世界中に影響が及ぶという現実を改めて示しています。 新人エンジニアの皆さんにとって、これは非常に重要な学びの機会です。システムを設計する際には、たとえAWSのような信頼性の高いクラウドサービスを使うとしても、「障害は起こり得る」という前提で考えることが大切です。例えば、重要なデータは複数の場所にバックアップを取る、または、複数のリージョンにシステムを分散配置して、一つがダウンしても別の場所でサービスを継続できるようにする（ディザスタリカバリや高可用性の設計）といった対策が考えられます。普段から障害への備えを意識することで、いざという時にサービスを守ることができるのです。 引用元: https://japan.cnet.com/article/35239420/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

関連リンク The Case for the Return of Fine-Tuning AIの世界では、一度は主流から外れていた「ファインチューニング」という技術が、再び大きな注目を集めています。これは、既存の大規模言語モデル（LLM）を、より特定の用途やデータに合わせて微調整する技術のことです。 かつて、Transformerモデルの登場により、ファインチューニングは効率的なモデル開発手法でした。しかし、LLMが非常に巨大化すると、モデル全体を再学習する「フルファインチューニング」は莫大な計算コストと時間が必要となり、実用的ではなくなりました。その代わりに、開発者はモデルへの指示を工夫する「プロンプトエンジニアリング」や、外部情報を参照させる「RAG（Retrieval-Augmented Generation）」を活用するようになりました。これらはモデルを再学習する必要がなく、手軽に良い結果を出せたからです。 ところが、2021年にMicrosoft Researchが発表した「LoRA（Low-Rank Adaptation）」という新しい手法が状況を変えました。LoRAは、モデルのほとんどの部分を固定し、ごく一部の小さな追加部分だけを学習することで、コストを大幅に削減しつつ、フルファインチューニングと同等の性能を引き出すことを可能にしました。Hugging FaceのPEFTライブラリもLoRAの実装を容易にし、ファインチューニングのハードルを大きく下げました。 現在、ファインチューニングが再び重要視されている主な理由は以下の通りです。 技術環境の整備: GPUを利用できるクラウドサービスが増え、LoRAのような効率的な手法が手軽に実行できるようになりました。 モデルの進化安定: LLMの進化が「革命的」から「進化的」になり、ファインチューニングしたモデルが無駄になりにくくなりました。 オープンソース化: MistralやLlamaのようなオープンなLLMが増え、企業が自社のニーズに合わせてモデルをカスタマイズしやすくなりました。 プロンプトの限界: プロンプトやRAGだけでは対応しきれない、企業独自の専門用語や話し方、複雑なルールなど、よりきめ細かなカスタマイズが求められるようになったからです。 Thinking Machines Labsの「Tinker」のような新しいプラットフォームは、ファインチューニングをさらに進化させています。例えば、LoRAの適用範囲を広げたり、学習率やバッチサイズといったパラメータを工夫したりすることで、より高性能なモデルを効率的に作れるよう提唱されています。現代のファインチューニングは、一つの大きなモデルを調整するだけでなく、ベースモデルと複数のLoRAアダプターを組み合わせて、用途に応じて柔軟に切り替える「モジュール式」へと進化しています。 モデルの評価にはまだ課題が残るものの、今後は運用中にフィードバックを受けて自動で学習し続ける「継続的学習」のような仕組みも期待されています。 ファインチューニングは、単なる技術的な調整を超え、企業がAIを自社のビジネスに合わせて深くカスタマイズし、独自の強みを生み出すための「戦略的な手段」として、その価値を高めています。AIをよりパーソナルに、より専門的に活用する未来において、この技術が果たす役割はますます大きくなるでしょう。 引用元: https://welovesota.com/article/the-case-for-the-return-of-fine-tuning LLM回答精度検証でテストデータやテストケースケースをAIに作ってもらう この記事では、LLM（大規模言語モデル）の回答精度を検証するために必要な「テストデータ」や「テストケース」を、AIと協力して効率よく作成する方法が解説されています。新人エンジニアの皆さんも、AIを上手に活用して開発作業を効率化するヒントが得られるでしょう。 まず、LLMを使った情報検索システム（例：Slackのメッセージ検索）の検証に使う「ダミーデータ」作りからスタートです。筆者は、実際のメッセージのJSONデータをAIに見本として渡し、「スレッド内のメッセージとスレッド外のメッセージを半々で100件作ってほしい」「改行や文字数のばらつきも入れてほしい」といった具体的な条件を細かく指定しました。AIはこれらの指示に応え、人間と対話しながら、より本物に近い、多様なメッセージデータを作り上げていきました。 次に、この作成したダミーデータを異なる形式に変換する作業もAIに依頼しました。例えば、読みやすいPretty JSON形式を、プログラムで扱いやすいOne-line JSONやCSV形式に変換したい場合です。筆者はAIに「JSON部分を1行にするスクリプトを作って」と指示したり、「CSV形式ならどんな形が良いか」と相談したりしました。AIは複数の変換案を提示し、筆者のフィードバック（例：「.で階層構造を表現する」）を受けて、最終的にPythonスクリプトを生成。このスクリプトを使うことで、適切な形式のデータが自動的に準備できました。 さらに、LLMの回答が正しいかを評価するための「テストケース」もAIと共に作成しました。当初、AIの提案は単純な「番号指定」のケースに偏っていました。そこで筆者は、AIに自身の提案を見直させる「critical-think」という機能を使ってみました。するとAIは、より多様な視点からのテストが必要だと自己認識し、「BigQueryについて話しているメッセージ」のような「内容ベース」の指定や、「U089VWX0YZAさんが投稿したメッセージ」のような「ユーザー名ベース」、さらには複数の条件を組み合わせた「複合条件」など、多角的なテストケースを再提案。スレッドの返信メッセージに関するテストも要望に応じて増やし、最終的にコメント付きでテスト設定ファイルに追記するまでをAIに任せました。 このように、LLMの検証に必要なテストデータやテストケースの作成において、AIは単に指示を実行するだけでなく、課題を認識し、より良い解決策を提案する強力なパートナーとなることが示されています。AIとの効果的な「壁打ち」を通じて、開発プロセス、特に検証フェーズの効率を大幅に向上させることができるという、現代のエンジニアリングにおいて重要な知見が得られるでしょう。 引用元: https://blog.shibayu36.org/entry/2025/10/15/173000 RAGでのデータ整形(改行・インデント)がLLMの回答精度に与える影響を検証した 今回の記事は、AIシステムの一つであるRAG（Retrieval Augmented Generation）において、大規模言語モデル（LLM）に渡すデータの「整形方法」（例えば、JSONデータを読みやすくするために改行やインデントを入れるかどうか）が、LLMの回答精度にどう影響するのかを検証した興味深いレポートです。 筆者は自身のプロジェクトで、トークン消費を抑えるためにデータを1行のJSON形式でLLMに渡していましたが、回答精度が不安定なことがあり、整形の影響について疑問を持っていました。そこで、この疑問を解決するために実験を行ったのです。 検証では、「oneline JSON（改行なしのJSON）」「pretty JSON（改行・インデントありのJSON）」「CSV」の3種類のデータ形式を用意し、最新のLLM（gpt-5, claude-sonnet-4-5など）と少し前のモデル（gpt-4.1-mini, claude-3-7-sonnetなど）を使って、特定の情報を抽出し、SlackのURLを生成できるかを試しました。 実験の結果、次の3つの重要な発見がありました。 データ整形は精度に大きな影響を与えない: データを見やすくするために改行やインデントを入れても、LLMの回答精度は特に向上しないことが分かりました。つまり、人間が読みやすい形式が、必ずしもLLMにとっても良いとは限らないということです。 LLMの性能向上で差がなくなる: 最新の高性能なLLM（特にgpt-5）では、どのデータ形式を使ってもほぼ100%の正答率を叩き出し、整形による精度の差はほとんどありませんでした。これは、LLMが賢くなればなるほど、データの見た目はそれほど気にしなくてよくなることを示唆しています。 トークン効率が重要: 精度に大きな差がないのであれば、RAGにおいてはLLMへの入力に使う「トークン数」を最も少なくできるフォーマットを選ぶのが賢い選択と言えます。トークン数が少なければ、それだけ処理コストも下がり、効率的です。今回の検証では、CSV形式が最もトークン消費が少なかったため、コスト面で有利である可能性が示唆されました。 この検証から、新人エンジニアの皆さんは、RAGシステムを設計する際に、データの見た目を整えることよりも、LLMの性能が十分高ければトークンコストを意識したデータ形式を選ぶことが効率的だと学べます。特に最新モデルを使う場合は、読みやすい整形にこだわるよりも、いかにコンパクトに情報を伝えられるかを考えると良いでしょう。 引用元: https://blog.shibayu36.org/entry/2025/10/14/173000 埼玉にある「ムーミンバレーパーク」へ行ってきた！ ムーミン屋敷のお宅訪問や思わず写真を撮りたくなる景色を紹介 埼玉県飯能市にある「ムーミンバレーパーク」の訪問記です。ムーミン屋敷の地下倉庫やキッチン、寝室を探検でき、インスタ映えする写真スポットも満載！原作を知らなくてもショートムービーで楽しめる工夫があります。料理動画投稿者さんならではの視点で、食卓やキッチンへの注目も面白いポイント。子ども向けの遊具やショーもあり、食事もテーマパークとしては良心価格。日々の業務の息抜きに、ムーミンの世界で癒されてみてはいかがでしょうか？ 引用元: https://news.nifty.com/article/item/neta/12237-4602453/ お便り投稿フォーム VOICEVOX:春日部つむぎ

youtube版(スライド付き) 関連リンク Cognition Introducing SWE-grep and SWE-grep-mini: RL for Multi-Turn, Fast Context Retrieval このブログ記事は、AIコーディングエージェントの「速さ」と「賢さ」という、これまでの課題を解決する新技術「SWE-grep」と「SWE-grep-mini」を紹介しています。これは、まるで人間のようにコードベースを理解・探索し、必要な情報を素早く見つけ出すためのAIモデルです。 これまでのAIコーディングエージェントは、複雑なタスクは得意でも、コード検索に時間がかかりすぎて開発者の作業を中断させてしまうという問題がありました。特に、AIエージェントが最初に情報を探し出す「文脈取得」の段階で、作業時間の60%以上を費やすこともあったそうです。 文脈取得の方法には主に2つありました。 埋め込み検索（RAG）: 事前の準備は速いものの、複雑なコードのつながりを追うような検索では不正確になる可能性がありました。 エージェントによる検索: 人間のようにCLIツール（コマンドラインツール）を使ってコードを探索するため柔軟ですが、何度もAIとのやり取りが発生し、非常に時間がかかりました。また、関係ない情報まで大量に読み込んでしまい、AIの判断を鈍らせる「コンテキスト汚染」という問題も抱えていました。 そこで登場したのが、今回発表された「SWE-grep」と「SWE-grep-mini」です。これらのモデルは、従来の最先端のAIコーディングモデルと同等の情報検索能力を持ちながら、なんと10倍も速く結果を返します。これにより、AIがコードを理解するためにかかる時間が大幅に短縮され、開発者はWindsurfというツールで「Fast Context（高速な文脈取得）」サブエージェントとして利用できるようになります。デモプレイグラウンドでもその速さを体験できます。 SWE-grepがこれほど高速な理由は以下の通りです。 並列ツール呼び出し: 複数の検索コマンド（grep、ファイル読み込みなど）を同時に実行することで、コードベースの様々な部分を効率よく探索します。従来のAIが1つずつ検索していたのを、同時に8つまで実行できるように訓練されています。 最適化されたツールと高速な推論: 検索ツール自体も高速化され、さらにCerebras社と協力してAIモデルの推論（思考）速度も大幅に向上させています。 これらのモデルは、強化学習（RL: Reinforcement Learning）というAIの訓練方法を使って開発されました。特に、報酬関数では、関連性の高い情報を正確に取得することを重視し、「コンテキスト汚染」を避けるように学習させています。 Cognition社は、この「Fast Context」技術を「Fast Agents」という、より広範な目標の第一歩と位置づけています。最終目標は、開発者が集中して作業できる「フロー状態」を維持し、ソフトウェア開発の生産性を最大限に高めることです。AIエージェントの応答速度が、開発者の作業効率に大きく影響すると考えており、わずか5秒という短い「フローウィンドウ」を目標に、AIの賢さと速さの両方を追求しています。 引用元: https://cognition.ai/blog/swe-grep AIエージェントを支える技術: コンテキストエンジニアリングの現在地 AIエージェントは、まるで人間のようにタスクをこなすための技術ですが、その性能を最大限に引き出すためには「コンテキストエンジニアリング」という技術が非常に重要です。新人エンジニアの皆さんも、この考え方を理解することで、AI開発の奥深さに触れることができるでしょう。 コンテキストエンジニアリングとは？ これは、大規模言語モデル（LLM）に与える「情報（コンテキスト）」をどう効率的に扱うかを考える技術です。特定のタスクに特化した指示の出し方であるプロンプトエンジニアリングに対し、コンテキストエンジニアリングは、AIが複数回の推論を伴う複雑なタスクをこなすための情報管理全般を指します。例えば、外部の情報を引っ張ってくるRAG（Retrieval Augmented Generation）もこの一部です。 なぜコンテキストエンジニアリングが重要なの？ LLMが一度に扱える情報量には限りがあります。情報が多すぎると、必要な情報が埋もれてしまう「Context Rot」という現象が起こり、AIは「本当に必要な情報だけを、適切な量で与える」ことが不可欠であることを示しています。この効率的な情報の与え方が、AIの出力品質を大きく左右するのです。 コンテキストエンジニアリングの3つの手法 情報の取得と生成 (Context Retrieval & Generation) AIがタスクを進める上で、必要な情報をリアルタイムで探し出し、準備する技術です。外部データベースからの情報取得や、ユーザーの質問をより適切な形に書き換えるなどが該当します。 情報の加工 (Context Processing) 取得した情報が使いにくい場合があるため、LLMが理解しやすいように加工します。不要な情報をフィルタリングしたり、長文を要約・圧縮したりします。また、AIに役割や振る舞いを教える「システムプロンプト」の設計や、少数の具体例（Few-shotプロンプティング）を効率的に提示することも含まれます。AIの処理を高速化する「KVキャッシュ」の最適化も重要です。 情報の管理 (Context Management) AIが過去に得た知識や経験を記憶し、次に活かすための技術です。一時的なメモ（Scratchpad）のような短期間の記憶と、永続的に保存される長期的な記憶があります。AIがタスクで失敗した際、その原因を記憶しておくことで、同じ失敗を繰り返さないようにするといった活用も可能です。複数のAIが協力する「マルチエージェント」の場合は、エージェント間で情報が共有され、整合性が保たれるように管理することが非常に重要になります。 コンテキストエンジニアリングは、AIエージェントをより賢く、より効率的に動かすための、まさに土台となる技術です。この知識を身につけることで、皆さんのAI開発スキルは格段に向上するでしょう。 引用元: https://tech.algomatic.jp/entry/2025/10/15/172110 【コピペOK】AIエージェントで良いコードを書く！誰でも使える品質向上ルールの設定方法 AIエージェントを使った開発はとても便利ですが、「動くコードは作ってくれるけど、品質は大丈夫かな？」と不安に感じることはありませんか？この記事は、AIエージェントに「良いコード」の基準を教え込み、コード品質を向上させるための「共通ルールファイル」の活用法を紹介しています。 なぜAIにルールが必要かというと、プログラミングにおける「良いコード」とは、ただ動くだけでなく、読みやすさ、修正のしやすさ、セキュリティ、処理速度など、さまざまな品質が求められる奥深いものだからです。AIエージェントは、私たちが何も指示しなければ、プロジェクトの文脈（例えば、試作品なのか、お客様に納品する本番用なのか）を自ら判断できないため、「とりあえず動くコード」を優先しがちです。だからこそ、私たちが「ルール」として明確な品質基準を教えてあげる必要があります。 「共通ルールファイル」は、AIに対する開発の指針をまとめたドキュメントで、まるで優秀な先輩エンジニアが隣でアドバイスしてくれるように、AIが常に品質を意識してコードを生成するようになります。このファイルは一度設定すれば、新しいプロジェクトごとに設定し直す必要がなく、多くのプロジェクトで共通の品質基準を保ちながら効率的に開発を進められるのが大きな利点です。 設定方法は非常に簡単で、Claude Code、Codex、Cursorといった主要なAIエージェントの場合、指定された場所にルールファイルを作成し、記事で提供されているルールをコピー＆ペーストするだけで完了します。 新人エンジニアの皆さんが特に意識すべき「良いコード」のポイントとして、記事では以下の8つの観点が紹介されており、これらをAIが考慮するように設定できることで、皆さんの学習にも繋がります。 エラーハンドリング: プログラムで問題が起きたときに、適切に対処し、ユーザーに状況を伝える。 セキュリティ: パスワードの隠蔽や悪意ある入力のブロックなど、プログラムの安全性を確保する。 保守性: 後から機能を追加したり、バグを修正したりしやすいように、整理されたコードを書く。 テスタビリティ: プログラムが正しく動くか確認（テスト）しやすい作りにする。 パフォーマンス: 処理速度が速く、効率的に動くコードにする。 信頼性: 問題が起きても安定して動作し続けるための仕組み（例：エラー時に自動で再試行）を持つ。 可観測性: プログラムが「今どんな状態か」を把握できるように、ログなどを記録する。 スケーラビリティ: 利用者が増えても対応できる、拡張しやすい作りにする。 この共通ルールファイルを使うことで、AIは「動くコード」だけでなく「良いコード」を生成する強力なパートナーとなります。初心者の方でも、AIがなぜそのコードが良いのかを説明してくれるため、実践しながらプログラミングスキルを高められるでしょう。設定はたった5分で終わるので、ぜひ試して、より楽しく、自信を持って開発を進めてみてください。 引用元: https://qiita.com/tomada/items/df5d3e0f611860bc2740 アニメとかでプール掃除でキャッキャイチャイチャしてる奴ら アニメで描かれるプール掃除は楽しいイベントのように見えますが、この記事は現実の厳しさをコミカルに指摘します。使っていないプールは苔でヌルヌル滑りやすく、怪我の危険も。水は緑色で悪臭が漂い、ヤゴやオタマジャクシがたくさんいるのが実際の姿だそう。プール掃除は重労働で、維持管理も大変だという現実を、クスッと笑える形で教えてくれる楽しい記事です。 引用元: https://anond.hatelabo.jp/20251016003851 お便り投稿フォーム VOICEVOX:ずんだもん

youtube版(スライド付き) 関連リンク Rails: Active Agent gemでRailsに適したAI機能の設計を考察する（翻訳）｜TechRacho by BPS株式会社 この記事は、RailsアプリケーションにAI機能を「Railsらしい」やり方で統合するための「Active Agent」gemについて、その設計思想や具体的な使い方、そして今後の可能性を、日本の新人エンジニアにも分かりやすく解説しています。 Active Agentは、Railsの「規約より設定（Convention over Configuration）」の原則を取り入れ、「Agent」という新しい抽象化を導入します。これは、Railsのコントローラやメーラーのように、AIによるテキスト生成などのロジックをカプセル化（ひとまとめにする）するものです。例えば、簡単なジョークを生成するエージェントも、Rails開発者には馴染み深いクラス定義とメソッド呼び出しで実現できます。AIへの指示文（プロンプト）もAction Viewのテンプレートとして管理できるため、コードとプロンプトを分離でき、変更や管理がしやすくなります。生成処理は、即座に結果を得る同期モードと、バックグラウンドで実行する非同期モードを選べます。 実際のプロジェクトでの活用例として、「オンデマンド翻訳機能」が紹介されています。翻訳エージェントが生成した訳文をデータベースに保存する際、エージェント内で直接データベースを更新するか、それともモデルに任せるかといった設計上の課題を議論し、より「Railsらしい」解決策としてモデル側にロジックを委譲する改善案を提示しています。 AI機能のテストについても触れています。外部のAIサービスに依存しないテストを実現するため、記事ではFakeLLMProviderという偽のAIサービスアダプタを自作する方法を紹介。これにより、本物のAPIを叩かずにAIの応答をシミュレートでき、テストの安定性と速度を向上させることができます。 もう一つの事例は、カンファレンスの「プロポーザルをAIがレビューする機能」です。このエージェントは、発表内容を評価するだけでなく、AIエージェントが過去の発表データベースを検索する「ツール機能」と連携することで、より的確な評価を可能にします。AIからの回答も、JSONのような構造化された形式で受け取れるよう設定でき、プログラムでのデータ処理が容易になります。 記事の後半では、AIアプリケーションの進化に必要な機能として、以下の点が挙げられています。 AI利用のクレジット管理とトラッキング 動的なプロンプト（状況に応じてAIへの指示文を変更） プロンプトインジェクション対策などのセキュリティ機能 複数のAIエージェントが連携する「エージェント型ワークフロー」 過去の会話を記憶する「LLMの記憶容量」 外部情報を活用するRAG（検索拡張生成）のような「コンテキストエンジニアリング」 Active Agentは、これらの複雑な要求にも対応できる拡張性を持っており、Rails開発者が愛するRailsフレームワークで、自然かつ効果的にAI機能を組み込めるようになることへの期待が示されています。 引用元: https://techracho.bpsinc.jp/hachi8833/2025_10_14/153720 ファインチューニングは死んだのか？Googleとスタンフォードの論文がAI学習の新しいパラダイムを提示 現在のAI（大規模言語モデルエージェント）は、一度失敗した経験から学ぶのが苦手で、同じ間違いを繰り返してしまうという課題を抱えています。まるで、毎回初めてのタスクとして取り組んでいるかのようです。しかし、Googleとスタンフォード大学の最新の研究が、この問題を解決し、AIがより賢く成長するための新しい方法を提案しています。 Googleが開発した「ReasoningBank（リーズニングバンク）」は、AIがタスクを実行した際の成功や失敗の経験を「記憶」として保存し、後で活用するシステムです。人間が日記をつけて過去の出来事を振り返るように、AIの「思考の過程（推論記録）」を構造化して記憶します。そして、新しいタスクに直面したとき、この記憶の中から似たような経験を探し出し、それを参考にして意思決定を行うのです。このシステムを導入したAIは、タスクの成功率が向上し、問題を解決するまでのステップ数も大幅に削減されました。失敗からも学ぶことで、AIは着実に経験を積んで賢くなっていきます。 一方、スタンフォード大学の「ACE（Agentic Context Engineering）」は、AIへの指示文（プロンプト）自体をAIが自律的に改善・進化させていくアプローチです。ACEは「タスクを実行するAI」「実行結果を評価するAI」「評価に基づいて指示文を更新するAI」という3つの役割を持つAIを組み合わせます。タスクの結果を見て、より効果的な指示文になるように、少しずつ改善を加えていくのです。この方法により、AIは状況に適応するまでの時間を大幅に短縮し、処理コストも削減できることが示されました。 これらの研究が示す共通の画期的な点は、AIの「ファインチューニング」と呼ばれる、AIモデルそのものを細かく調整する作業なしに、AIが学習し、性能を向上させられることです。ReasoningBankはAIに外部の「記憶」を与え、ACEはAIの「指示の仕方」を内部的に最適化します。 これにより、AIは単なる計算ツールではなく、まるで人間のように「経験を積みながら自分で学習し、成長していく」新しいフェーズに入りつつあります。AIが「どうすればもっとうまく学習できるか」を自ら学び始める、そんな「記憶を持つエージェント」の時代が到来するかもしれません。これは、AI開発の未来にとって非常に重要な一歩となるでしょう。 引用元: https://note.com/trans_n_ai/n/n92f8092bff4c Introducing Claude Haiku 4.5 Anthropicから、最新の小型AIモデル「Claude Haiku 4.5」がリリースされました！日本の新人エンジニアの皆さんにとって、これはAI開発の現場で「速くて賢いAIを、もっと手軽に使えるようになる」という、とても嬉しいニュースです。 このHaiku 4.5の最大のポイントは、「高性能なのに、ものすごく速くて、しかも安く使える」という点です。なんと、たった5ヶ月前に最先端だった「Claude Sonnet 4」というモデルと比べて、ほぼ同等のコーディング性能を持ちながら、コストは3分の1、速度は2倍以上も向上しています。つまり、以前なら高価で時間のかかったAIの処理が、これからはもっと気軽に試せるようになるわけです。 例えば、AIにリアルタイムでチャットアシスタントをさせたり、お客様対応をさせたり、あるいはプログラミングのペアを組ませるような、応答速度が重要な場面でHaiku 4.5は大活躍します。特に、複数のAIエージェントを使った複雑なプロジェクトや、手早く試作を作りたいラピッドプロトタイピングなど、コーディング作業全般で、これまで以上にサクサクと開発を進められるようになるでしょう。 Anthropicには、現在世界最高のコーディングモデルとされる「Claude Sonnet 4.5」もあります。Haiku 4.5はSonnet 4.5ほどの「究極の知性」は追求していませんが、それに匹敵する性能を「圧倒的なコスト効率」で提供します。状況に応じて、Sonnet 4.5で複雑な問題を分解し、細分化されたタスクを複数のHaiku 4.5に並行して処理させる、といった賢い使い方もできるようになります。 開発者の皆さんは、Claude APIを通じて「claude-haiku-4-5」としてすぐに利用を開始できます。料金も非常に経済的で、入力100万トークンあたり1ドル、出力100万トークンあたり5ドルという設定です。Amazon BedrockやGoogle Cloud Vertex AIでも利用可能なので、普段使っている環境からアクセスしやすいのも魅力です。 安全性にもしっかり配慮されており、Haiku 4.5はこれまでのモデルと比べて不適切な振る舞いをする割合が大幅に低減されています。これは、AIを安心して活用するために非常に重要な点ですね。 Haiku 4.5の登場は、AI開発のハードルをさらに下げ、より多くのアイデアを迅速に形にできる可能性を広げてくれます。新人エンジニアの皆さん、ぜひこの新しい強力なツールを使いこなして、これからのAI開発を楽しんでいきましょう！ 引用元: https://www.anthropic.com/news/claude-haiku-4-5 『ジブリ風』と言われるAI生成画像、使わない層はどう思っているのか「この絵柄はもはや『OpenAI風』という印象」「この色ホント苦手」 「ジブリ風」と称される特定のAI生成画像がSNSで話題です。多くのユーザーはこれを「OpenAI風」と認識し、本来のジブリとは異なるという意見が出ています。特に、画像特有の黄ばんだ色味や人工的な違和感に不満の声が上がっています。このAI画像は中高年層に多く利用される一方、若年層からは古く感じられており、世代間で美的感覚のギャップが指摘されています。AIが作り出す表現が社会にどう受け入れられるか、エンジニアとして考えるきっかけになるでしょう。 引用元: https://togetter.com/li/2615953 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク Make agents a reality with Amazon Bedrock AgentCore: Now generally available Amazon Web Services AWSから、AIエージェントを開発し、実際のビジネスで活用するための新しいプラットフォーム「Amazon Bedrock AgentCore」が一般提供開始されました。これは、これまで試作段階にとどまりがちだったAIエージェントを、安全性、信頼性、スケーラビリティを確保しながら、本格的なサービスとして運用するための基盤となるものです。 AIエージェントとは、まるで人間のアシスタントのように、自律的に考え、タスクを遂行するプログラムのことです。例えば、ユーザーの質問に答えたり、情報を収集したり、複数のシステムを連携させて複雑な業務を自動化したりできます。しかし、これを企業レベルで安全かつ効率的に運用するには、多くの技術的な課題がありました。AgentCoreは、そうした課題を解決し、開発者がエージェントを素早く本番環境に導入できるように設計されています。 AgentCoreの主な特徴は以下の通りです。 柔軟な開発: 開発者は、Amazon Bedrockで提供されるAIモデルだけでなく、OpenAIやGoogle Geminiなど外部のモデル、そしてLangChainやCrewAIといったお好みの開発フレームワークを使って、自由にエージェントを構築できます。 豊富なツール連携: エージェントがコードを安全に実行できる「Code Interpreter」や、ウェブサイトを操作できる「Browser」機能が組み込まれています。また、既存の社内システムやAPIをエージェントから簡単に呼び出せるようにする「Gateway」機能もあり、エージェントはより多くのタスクを実行できるようになります。 賢い記憶力: 過去の会話や操作履歴を覚え、文脈を理解しながら対応する「インテリジェントメモリ」機能により、エージェントはより賢く、パーソナルな体験を提供できます。 運用と監視: エージェントの動作を詳細に監視し、問題が発生した場合に素早く原因を特定できる機能（Observability）が提供されます。また、予測不能な負荷にも自動で対応し、長時間のタスクでも安定して稼働できる信頼性の高い実行環境（Runtime）も備わっています。 高いセキュリティ: 高度なセキュリティ機能が組み込まれており、機密データを安全に扱いながら、企業システムにアクセスできます。 すでに、Amazon社内の製造プロセス自動化、医療分野での承認審査効率化、通信大手エリクソンやソニーグループでのAI活用など、様々な業界でAgentCoreが活用され、大きな成果を上げています。 AgentCoreは東京リージョンを含む世界9つのAWSリージョンで利用可能なので、日本のエンジニアの皆さんも、これらの強力な機能を使って、アイデアを素早く形にし、AIエージェントの可能性をビジネスに活かしていくことができます。 引用元: https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-is-now-generally-available/ Securing your agents with authentication and authorization AIエージェントは、チャットだけでなく、ファイル操作やメッセージ送信、外部ツールの利用といった「行動」ができる点が大きな特徴です。そのため、従来のAIアプリケーションよりもセキュリティ対策が重要になります。特に「認証（Authentication）」と「認可（Authorization）」は、エージェントを安全に運用するために欠かせない要素です。 認証（AuthN）と認可（AuthZ）の基本 認証とは「あなたが誰であるか」を確認するプロセスです。例として、システムにログインする際にユーザー名とパスワードで本人確認をするのが認証です。一方、認可とは「認証されたあなたが何ができるか」を判断し、アクセス権限を制御するプロセスです。この二つは合わせて「認証認可（Auth）」と呼ばれ、あらゆるアプリケーションで重要ですが、AIエージェントには特有の課題があります。 AIエージェントが従来のアプリケーションと違う点 多くのサービスへのアクセス: エージェントは、従来のアプリケーションよりもはるかに多くの異なるサービスやツール（例：メール、カレンダー、データベースなど）にアクセスする必要があります。 動的に変化するアクセス要件: エージェントの行動は、その時々の状況によって必要な権限が大きく変わるため、柔軟なアクセス制御が必要です。 監査の複雑さ: 多くのサービスをまたいで行動するため、エージェントが行った操作の記録（監査ログ）があちこちに分散し、全体の動きを追跡・確認するのが難しくなります。 これらの課題に対応するため、将来的にはエージェントの認証認可を一元的に管理する新しいシステムが必要になると考えられています。しかし、現在の技術でもエージェントのセキュリティは確保できます。 現在のAIエージェントの認証認可 エージェントも基本的にはリソースにアクセスするソフトウェアであるため、既存の認証認可技術である「OAuth 2.0」や「OIDC」といった業界標準のフレームワークを効果的に利用できます。エージェントのアクセスパターンは大きく二つに分けられます。 委任アクセス (Delegated Access): エージェントがユーザーの「代理」としてリソースにアクセスする場合です。例えば、メールアシスタントがユーザーの許可を得てメールボックスにアクセスし、メールを処理するようなケースです。 この場合、「Auth Code Flow」と「OBO (On-Behalf-Of) Token Flow」といったOAuth 2.0のフローが主に使われます。 直接アクセス (Direct Access): エージェントが人間の関与なしに、自律的にリソースにアクセスする場合です。例えば、セキュリティエージェントが自動でシステムログを監視し、異常を検知するようなケースです。 この場合、「Client Credentials Flow」というOAuth 2.0のフローが主に使われます。 まとめ AIエージェントの能力が高まり、自律性が増すにつれて、認証認可の重要性はますます高まります。OAuth 2.0などの既存の標準技術を理解し、適切に活用することが、安全なエージェントを開発するための第一歩です。特に「Auth Code Flow」「OBO Token Flow」「Client Credentials Flow」の3つのフローは、多くのエージェントにおけるアクセス制御で役立つでしょう。 引用元: https://blog.langchain.com/agent-authorization-explainer/ StreamingVLM: Real-Time Understanding for Infinite Video Streams 最近注目されている「画像とテキストを同時に理解するAIモデル（VLM）」は、私たちが普段使っているAIアシスタントや、自動運転のような自律的に動くシステムにおいて、動画をリアルタイムで理解するための鍵となります。しかし、現在のVLMには大きな課題がありました。それは、終わりなく続く長い動画ストリームを処理する際に、システムが遅くなったり、メモリを使いすぎたりすることです。 従来のやり方では、動画全体を一度に処理しようとすると、動画が長くなるほど計算量が爆発的に増え（動画の長さの2乗に比例！）、現実的ではありませんでした。また、動画を区切って少しずつ処理する「スライディングウィンドウ方式」という方法もありますが、これだと動画全体の文脈が途切れてしまったり、同じ部分を何度も計算し直すために無駄な処理が多く発生し、結局遅延につながっていました。 このような課題を解決するため、この論文では「StreamingVLM」という新しいモデルを提案しています。StreamingVLMは、無限に続く視覚情報（動画）を、リアルタイムかつ安定して理解できるように設計されています。 彼らのアプローチのポイントはいくつかあります。 まず、AIモデルの学習方法と、実際に動かす推論方法を統一した枠組みで考えることで、より効率的な処理を実現しています。 推論時には、AIが過去の情報を記憶しておくための「KVキャッシュ」という領域をコンパクトに保つ工夫がされています。具体的には、重要な情報（アテンションシンク）を再利用したり、直近の短い動画フレームの情報と、直近の長いテキストの情報をうまく組み合わせたりして、必要な情報だけを効率的に保持します。 このリアルタイム処理能力は、シンプルな「教師ありファインチューニング（SFT）」という学習方法によって実現されています。これは、全体を一度に見るのではなく、短いながらも少しずつ重なる動画の塊（チャンク）を使って学習させることで、非常に長い動画を処理するための特殊な学習をせずとも、実際の推論時と同じようなアテンションの動きをモデルに覚えさせることができます。 StreamingVLMの性能を評価するために、研究チームは平均2時間以上という超長時間の動画を含む、新しい評価基準「Inf-Streams-Eval」を作成しました。このベンチマークで、StreamingVLMは競合する「GPT-4O mini」に対して66.18%の勝率を達成し、NVIDIA H100という高性能なGPU一枚で、1秒間に最大8フレームという安定したリアルタイム処理を実現しています。さらに、このSFT学習戦略は、特定の画像質問応答（VQA）タスク向けのチューニングなしに、一般的なVQA能力も向上させ、他の主要なベンチマークでも優れた結果を出しています。 このStreamingVLMは、将来のAIアシスタントや自律エージェントが、長く続く動画をスムーズに理解し、より賢く、より役立つ存在になるための重要な一歩と言えるでしょう。コードも公開されており、さらなる発展が期待されます。 引用元: https://arxiv.org/abs/2510.09608 イラストレーターさん「あなたの愛猫を描きます！」企画に寄せられた猫の開き画像が豪快すぎて笑顔になる イラストレーター「はいらずんば@猫スケッチ」さんの「あなたのうちの子描きます」企画が注目を集めました。応募された写真の中でも、大胆に寝そべる猫の「豪快な開き」ポーズが特に話題に。「お股パッカーン」や「お手てのむん！」といった可愛らしい姿が多くの人の笑顔を誘い、SNS上で大きな反響を呼んでいます。猫の愛らしい一面が心を和ませる、楽しいニュースです。 引用元: https://togetter.com/li/2615511 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク The Tiny Teams Playbook この記事は、AIエージェントの進化が加速する現代において、少人数ながらも高い生産性を誇る「Tiny Teams」の成功戦略をまとめたものです。日本の新人エンジニアの皆さんが、これからのチームでの働き方やAIとの協業を考える上で、貴重なヒントとなるでしょう。 「Tiny Teams」とは、従業員数よりも多くの年間経常収益（ARR）を生み出す、極めて効率的なチームのことです。AIが知識労働を自動化・拡張できるようになった今、AIを最大限に活用し、スピードと効率性で大きな成果を出す新しい組織の形として注目されています。 AI Engineer Summitで共有された、成功しているTiny Teamsからの普遍的なアドバイスは以下の通りです。 採用 (Hiring) 厳選された優秀人材: 真に期待できる候補者のみ採用。 有給ワークトライアル: 短期間のプロジェクトで適性を見極める。 製品からの採用: サービスに熱意ある顧客をチームに招く。 高水準の報酬: 優秀な人材には、相応の給与で高いモチベーションを維持。 少人数のベテラン「ジェネラリスト」: 幅広いスキルを持つ経験豊富なメンバーで構成。 文化と価値観 (Culture & Value) 「低エゴ、高信頼」: 信頼に基づき、迅速な意思決定を促進。 自立心、粘り強さ、レジリエンス: 困難に屈せず、解決策を探す姿勢。 徹底した透明性と責任: 進捗や課題を共有し、各自が責任を持つ。 ユーザー中心: 顧客のフィードバックを重視し、喜ばれる製品開発。 連帯感とスピード: 楽しみながら素早く行動し、チームの活力を維持。 運営 (Operations) 会議を最小限に: 「深い集中」の時間を確保し、生産的な作業を優先。 AIを「Chief of Staff」として活用: リサーチやマーケティングをAIで自動化。 AIによるカスタマーサポート: 顧客対応の効率化と品質向上。 優先順位付け（Let Fires Burn）: 重要な課題に集中し、全てを解決しようとしない。 「二度と学ばない」知識共有: 再利用可能なテンプレートで効率的な学習と活用。 対面での交流: オフィスや合宿でチームの結束を強化。 技術と製品 (Tech and Product) シンプルで堅実な技術スタック: メンテナンスしやすく信頼性の高い技術を選択。 シンプルな製品から開始: 核となる機能に絞り、迅速にリリース。 フィーチャーフラグによる実験: 新機能を段階的に導入し、ユーザーの反応を確認。 独自のベンチマーク作成: LLMの性能評価など、製品改善のための評価システムを構築。 これらの戦略は、AIを活用し大きな成果を出しているチームから学んだ知見です。新人エンジニアの皆さんも、効率的なチームのあり方やAIとの協業について考える上で、ぜひこれらのヒントを活用してください。 引用元: https://www.latent.space/p/tiny Every LLM Is Its Own Media Channel AIVO Journal LLMは全部同じじゃない！それぞれのAIで「情報の見つけ方」が違う理由 多くのエンジニアやマーケターは、ChatGPT、Gemini、ClaudeのようなLLM（大規模言語モデル）を「AI」として一括りに見てしまいがちです。しかし、この記事は、これらのLLMがそれぞれ独自の「情報の収集方法」や「評価基準」を持つ、全く異なる情報チャネルであると警鐘を鳴らしています。まるでGoogle、Meta、TikTokを同じものとして扱うのが間違いであるように、LLMも個別に戦略を立てる必要があるというのです。 なぜLLMごとに情報の見つけ方が違うのでしょうか？ ChatGPT-4o/o1: 特徴: 「最新の情報」と「信頼できる情報源」を非常に重視します。タイムスタンプが新しく、人間がレビューした情報や、公式なライセンスを持つメディアのコンテンツが優先されます。 ポイント: 情報の「鮮度」と「出どころの信頼性」が鍵です。 Gemini 1.5 Pro: 特徴: Googleの知識グラフ（Knowledge Graph）と深く連携し、「具体的な『モノ』や『概念』と結びついたデータ（エンティティリンクされたデータ）」を重視します。情報が決められたデータ形式（スキーマ）で構造化されていると、見つけてもらいやすくなります。 ポイント: 情報が「何について」のもので、その構造が「明確である」ことが重要です。 Claude 3.5 Sonnet/Opus: 特徴: 「情報の信頼性」と「倫理的な価値観との整合性」を厳しく評価します。過度に最適化されたり、推測に基づいたりするコンテンツは評価が低く、専門家が監修し、中立的な表現で、安全性が確認された情報を好みます。 ポイント: 情報の「客観性」と「質の高さ」が求められます。 これらのLLMが今後も統合される可能性は低いと筆者は指摘します。それは、データ収集のライセンスや各国・地域の法律（ガバナンス）が異なるため、各LLMが独自のエコシステムとして進化していくからです。 新人エンジニアが意識すべきこと LLMを活用したサービスやアプリケーションを開発する際、この違いを理解することが非常に重要です。 データの準備: 各LLMが重視するポイントに合わせて、データの鮮度、構造化、信頼性を考慮して準備しましょう。 プロンプト設計: 例えば、ChatGPTには最新情報へのアクセスを促すプロンプト、Geminiには構造化されたデータの参照を促すプロンプト、Claudeには中立的で信頼できる情報源を求めるプロンプトなど、LLMの特性を活かした設計が求められます。 コンテンツ作成: LLMに生成させるコンテンツや、LLMが参照する外部コンテンツを作成する際も、それぞれのLLMの評価基準に合致するように工夫が必要です。 まとめると、LLMは「単一のAI」ではなく、「個別の特性を持つ情報収集・評価システム」です。それぞれのLLMの個性を見極め、それに合わせたアプローチを取ることが、これからのAI時代で成功するための重要な視点となるでしょう。 引用元: https://www.aivojournal.org/every-llm-is-its-own-media-channel/ Huawei、LLMの精度を保持したまま最大70%メモリ削減できる新手法を発表──コンシューマーGPUでの高精度生成AI実行も視野に Ledge.ai Huaweiが、大規模言語モデル（LLM）をもっと手軽に、そして高性能なGPUがなくても利用できるようにする画期的な新技術「SINQ（Sinkhorn-Normalized Quantization）」を発表しました。これは、AIの精度を保ったまま、AIが動くコンピューターのメモリ使用量を大幅に削減できる技術です。 最近注目されているChatGPTのようなLLMは非常に賢いですが、動かすためには膨大なメモリ（VRAM）を積んだ高性能なグラフィックボード（GPU）が必要です。そのため、多くの人が手元のPCで気軽に試したり、スマートフォンなどの小さなデバイスにAIを組み込んだりするのは難しいという課題がありました。 SINQは、AIモデルのデータ（重み）を「量子化」という技術で圧縮し、メモリ消費を抑える手法です。従来の量子化では、データを圧縮するとAIの精度が落ちてしまいがちで、その精度を元に戻すために「再調整（キャリブレーション）」という手間のかかる追加作業が必要でした。しかし、SINQの最大の特徴は、この再調整が一切不要になる点です。 この技術の核となるのは、「Sinkhorn-Knoppアルゴリズム」という数学的な手法の応用です。AIモデルの重みデータに存在する「外れ値」（極端に大きい・小さい値）が特定の場所に偏るのを防ぎ、データ全体が均一に分散されるように調整します。これにより、データを大幅に圧縮しても、AIの予測精度をほとんど損なうことなく維持できるのです。 具体的な成果としては、AIの精度を高く保ったまま、メモリ使用量を最大70%も削減できます。これは非常に大きな進歩で、例えば、私たちが普段使うような8GB程度の一般的なグラフィックボードでも、これまで専門的な高性能GPUでしか動かせなかったような大規模なLLM（Qwen3-7Bモデルなど）を動かせるようになることを意味します。さらに、データ圧縮の処理自体も非常に高速で、従来の再調整が必要な手法と比べて最大30倍も速いと報告されています。 SINQは、HuaweiのQwenシリーズだけでなく、Llama 2やLlama 3など、様々なLLMに適用できる汎用性の高さも魅力です。これにより、高性能なGPUに頼らずにLLMを運用する道が開かれ、手元のPCやエッジデバイス（小型の端末）でも高品質な生成AIが使える未来が近づきます。この技術のコードはGitHubで公開されており、世界中のエンジニアが自由に試したり、さらに応用したりすることが期待されています。 この技術は、将来皆さんが少ないリソースでAIアプリを開発したり、AIを様々な製品に組み込んだりする際に、とても役立つ基礎技術になるでしょう。AIの可能性を広げる、重要な一歩と言えます。 引用元: https://ledge.ai/articles/huawei_sinq_quantization_llm カイジの絵が下手だと思っていた時期があったが、いざ模写してみると圧倒的な上手さに気づいた話「ピカソの絵を下手だと評することと同じ」 漫画『カイジ』の絵は、独特なタッチのため『下手』と思われがちですが、実はプロも認める『圧倒的な巧みさ』を持つと話題です。実際に模写すると、キャラクターの個性、読者を惹き込む視線誘導、コマ割り、心理描写といった『漫画としての総合力』の高さに気づかされます。これは表面的な印象で判断せず、奥にある本質や技術を見抜く大切さを教えてくれます。新人エンジニアの皆さんも、一見シンプルなものに隠された深い工夫を探求する視点を持つ良いきっかけとなるでしょう。 引用元: https://togetter.com/li/2615004 お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）

youtube版(スライド付き) 関連リンク From Assistant to Adversary: Exploiting Agentic AI Developer Tools 最近、CursorやGitHub CopilotといったAIを活用した開発ツールが広く利用され、開発効率の向上に貢献しています。しかし、この記事ではこれらの「自律型AI開発ツール」が新たなセキュリティ上の脅威をもたらす可能性と、その対策についてNVIDIAが分析した内容を解説しています。 自律型AI開発ツールは、LLM（大規模言語モデル）の力で、ユーザーの指示やコードを理解し、ファイルの編集、コマンド実行といった様々なアクションを自律的に行います。この自律性が開発を加速させる一方で、AIエージェントが行動できる範囲が広いほど、その動作は予測しにくくなり、攻撃者による悪用のリスクが高まることが指摘されています。 記事では、攻撃者がGitHubのプルリクエストやイシューに巧妙に悪意のある指示（「間接プロンプトインジェクション」）を仕込むことで、開発者のPCで不正なコードを実行させる具体的な手口が紹介されています。例えば、攻撃者は一見無害な偽のPythonパッケージを作成し、それをプロジェクトの依存関係として追加するプルリクエストを送信します。もし開発者がAIエージェントを使ってこのプルリクエストをレビューさせると、エージェントがそのパッケージをインストールする際に、パッケージに仕込まれた悪意のあるコード（例えば、PCを遠隔操作されるリバースシェル）が実行されてしまう可能性があります。Cursorのようなツールには一定のセキュリティ対策が講じられていますが、記事では巧妙な手法でこれらの対策を迂回できる場合があることも示されています。 このような攻撃から身を守るために、以下の対策が推奨されています。 「プロンプトインジェクションは常に起こり得る」という前提でAIシステムを設計する。 AIエージェントの自律性をできるだけ制限し、特定の決まった作業のみを許可する。 信頼できないデータ（外部からのプルリクエストなど）を扱う際には、必ず人間が内容を確認し承認する仕組み（Human-in-the-loop）を導入する。 もし完全な自律稼働が必要な場合は、仮想マシン（VM）やコンテナのような隔離された環境でエージェントを実行し、アクセスできるリソースを最小限に抑える。 NVIDIAが提供する脆弱性スキャナー「garak」や、安全なやり取りをサポートする「NeMo Guardrails」のようなツールを活用することも有効です。 AIエージェントの活用は開発を大きく加速させる可能性を秘めていますが、その潜在的なリスクを正しく理解し、適切なセキュリティ対策を講じることが、安全に開発を進める上で不可欠です。 引用元: https://developer.nvidia.com/blog/from-assistant-to-adversary-exploiting-agentic-ai-developer-tools/ Embracing the parallel coding agent lifestyle 皆さん、こんにちは！今回は、複数のAIコーディングエージェントを同時に活用して、ソフトウェア開発を効率的に進める新しい働き方についてご紹介します。筆者自身も最初は懐疑的でしたが、実践してみると非常に効果的だと感じているそうです。 このアプローチは、AIに得意な作業を複数並行して任せることで、私たちエンジニアがコードのレビューや設計など、より重要なタスクに集中できるようになる、という考え方に基づいています。新人エンジニアの皆さんも、ぜひこの発想を取り入れてみてください。 具体的に、AIエージェントを並行して使うことで、どのような作業が効率化できるのでしょうか？ 新しい技術の調査や概念実証（PoC）: 「この新しいライブラリは使えるか？」「この技術で何ができるか？」といった、未知の領域を探る初期段階の作業をAIに任せます。AIは関連するコードを読み解き、プロトタイプを作成してくれるので、私たちが手探りで調べる手間を大幅に削減できます。 既存システムの動作原理の確認: 自分のプロジェクトのコードベースで「この機能はどう動いているんだっけ？」と疑問に思った時、AIに質問すれば、コード全体を分析し、詳細な説明を短時間で提供してくれます。これにより、複雑なシステムの理解を素早く深めることができます。 小さなメンテナンスや軽微な修正作業: テスト実行中に発生する警告の解消や、簡単なバグ修正など、本来であれば集中力を妨げるような細かい作業をAIに依頼できます。メインの作業を中断することなく、AIが裏でこれらの「ちょっとした困りごと」を解決してくれるので、非常にスムーズです。 具体的な指示に基づく開発作業: 「こういう機能を作ってほしい。実装方法も具体的に指示する」というように、詳細な仕様をAIに与えることで、期待通りのコードを生成させることができます。これにより、生成されたコードのレビューにかかる時間も短縮され、効率的に開発を進められます。 筆者は現在、複数のAIエージェントを様々な環境で同時に動かし、並行処理を行う開発スタイルを実践しています。リスクの高い作業では、万が一の事態に備えて安全な方法を選ぶなど、状況に応じた使い分けが重要です。AIを駆使した開発はまだ発展途上ですが、LLM（大規模言語モデル）の進化によってその可能性は大きく広がっています。新人エンジニアの皆さんも、この新しい働き方を積極的に試し、自身の生産性向上につなげていきましょう。 引用元: https://simonwillison.net/2025/Oct/5/parallel-coding-agents/ OpenAI Agent Builderを触ってみた：Difyとの違いと実践Tips OpenAIが2025年にリリースした「Agent Builder」は、AIエージェントの開発をぐっと身近にする新しいツールです。コードを書かなくても、視覚的にノードを繋いでワークフローを組み立てられるため、初心者でも直感的にAIエージェントを作ることができます。開発は「設計」「公開」「デプロイ」の3ステップで、プレビュー機能で動作をすぐに確認できるため、効率的に試行錯誤できます。 類似ツールであるDifyとの比較では、Agent BuilderはOpenAI公式のため、GPT-5などの最新モデルやChatKitとの連携がスムーズで、シンプルさとセキュリティが標準で備わっています。一方Difyはオープンソースで、多様なLLM（大規模言語モデル）に対応し、カスタマイズ性が高く、オンプレミス運用も可能です。OpenAIの技術を素早く試したいならAgent Builder、より柔軟な開発や自社環境での運用が必要ならDifyを選ぶのが良いでしょう。 Agent Builderのワークフローは、「Agent（AIモデル本体）」「File Search（検索）」「If/else（条件分岐）」などのノードを組み合わせて作成します。エージェントを設計する際は、一つのエージェントに多くの役割を持たせるのではなく、「質問分類」「情報検索」「回答生成」のように役割を分担させると、より良い性能を発揮します。 AIエージェントは悪意のある入力に弱いため、セキュリティ対策が欠かせません。「プロンプトインジェクション」や「データ漏洩」を防ぐために、出力形式の制限、人間による承認（Human approval）、Guardrailsといった機能を使うことが推奨されます。特に外部ツールと連携する際は、慎重な設定が必要です。 作成したエージェントは、ChatKitを使えば簡単にウェブサイトなどに組み込んでチャットUIとして利用できます。 開発をスムーズに進めるための実践的なヒントもあります。例えば、既存のテンプレートから始めること、ワークフローにコメントを残して設計意図を明確にすること、開発中のコスト（トークン消費）を意識すること、そしてエージェントの品質を定期的に評価することです。また、安全性とユーザー体験のバランスを考え、データ削除や外部送信など本当に重要なアクションにのみ人間による承認（Human approval）を配置しましょう。 Agent BuilderはAIエージェント開発のハードルを下げ、多くのアイデアを形にする可能性を秘めています。セキュリティ対策やコスト管理をしっかり行いながら、新しいAIプロダクト開発に挑戦してみましょう。 引用元: https://qiita.com/akira_papa_AI/items/7344e21b9204526e5127 世界最小の哺乳類「トウキョウトガリネズミ」を見に行ってきた！ 東京にいなくてネズミでもない“トガリネズミ”は、可愛い姿で毒を使うハンターだった 東京にはいない「トウキョウトガリネズミ」は、ネズミではなくモグラの仲間で、体重わずか2gの世界最小哺乳類です。4時間以上食べないと餓死するほど代謝が速く、なんと毒を使って獲物を麻痺させるハンターでもあります。北海道に生息する絶滅危惧種で、可愛らしい見た目と意外な生態のギャップが魅力。熱心な投稿者が展示会に足繁く通って撮影した、貴重なトガリネズミたちの動画が話題になりました。 引用元: https://news.nifty.com/article/item/neta/12237-4573333/ お便り投稿フォーム VOICEVOX:ずんだもん

youtube版(スライド付き) 関連リンク Introducing the Gemini 2.5 Computer Use model Google DeepMindは、AIがコンピューターのユーザーインターフェース（UI）を直接操作できるようになる画期的な新モデル「Gemini 2.5 Computer Use」を発表しました。このモデルは、Gemini 2.5 Proの持つ「見て、考えて、判断する」高度な視覚理解と推論能力をベースに開発されており、AIエージェントがまるで人間のようにWebサイトやアプリケーションを操作できるようにすることを目的としています。 このモデルの大きな特徴は、Webやモバイルの制御に関するテスト（ベンチマーク）において、既存のどのモデルよりも高い性能を発揮し、しかも応答速度（レイテンシー）が非常に速い点です。具体的には、Webページのフォームに情報を入力したり、ドロップダウンメニューを選んだり、ログインが必要なページを操作したりといった、これまでAIだけでは難しかったデジタルタスクをスムーズにこなすことができます。 技術的な仕組みとしては、Gemini APIを通じて提供される「computer_use」という特別なツールを使います。AIは、現在の画面のスクリーンショット、ユーザーからの指示、そして過去にどのような操作をしたかという履歴情報を受け取ります。これらを分析して、「このボタンをクリックする」「ここに文字を入力する」といった具体的なUIアクションを判断し、実行します。もし、購入などの重要な操作が必要な場合は、ユーザーに確認を求める機能も備わっています。この一連のプロセスを繰り返すことで、AIが自律的にタスクを完了させることが可能です。現在のところ、主にWebブラウザでの操作に最適化されていますが、モバイルアプリのUI制御においても大きな可能性を秘めています。 AIがコンピューターを直接操作できるようになるため、Google DeepMindは安全性を非常に重視しています。モデル自体に、意図しない誤操作や悪用を防ぐための安全機能が最初から組み込まれています。さらに、開発者向けにも、システムを破壊したり、セキュリティを侵害したりするような高リスクなアクションをAIが勝手に実行しないよう、細かく設定できる安全制御機能が提供されています。Googleは、この新しい技術を導入する際には、開発者がシステムを徹底的にテストするよう強く推奨しています。 すでに早期アクセスプログラムでは、このモデルが様々な分野で活用され、大きな成果を上げています。例えば、ソフトウェア開発におけるUIテストの自動化により、開発スピードが飛躍的に向上したり、個人のタスク管理アシスタントや企業内のワークフロー自動化に利用されたりしています。Google社内でも、決済プラットフォームの脆いUIテストをAIが自動で修復するといった活用例があり、最大で60%以上のテストをAIが立て直すことに成功しているとのことです。 この「Gemini 2.5 Computer Use」は現在、Google AI StudioやVertex AIを通じて、パブリックプレビュー版として利用可能です。日本の新人エンジニアの皆さんも、この新しいAI技術に触れて、未来の自動化やAIエージェント開発の可能性をぜひ体験してみてください。 引用元: https://deepmind.google/discover/blog/introducing-the-gemini-2-5-computer-use-model/ Agents Playwright 「Playwright Agent」は、人気のWebテストフレームワークPlaywrightに標準で組み込まれた、AIの力を活用したテスト自動化支援機能です。新人エンジニアの皆さんにとっては、テストコードを書く手間を大幅に減らし、より効率的に品質の高いWebアプリケーションを開発できるようになる、強力なツールだと考えると良いでしょう。 このPlaywright Agentには、主に3つの「エージェント」と呼ばれる仕組みが含まれています。これらはそれぞれ異なる役割を持ち、連携しながらテストの作成から修復までを自動的に進めます。 🎭 Planner（プランナー）: このエージェントは、皆さんのWebアプリケーションを自動的に探索し、「何をテストすべきか」という計画を、人間が理解しやすいMarkdown形式のドキュメントとして作成します。例えば、「ユーザーが商品をカートに追加し、購入を完了する」といった具体的なシナリオを設計する手助けをしてくれます。 🎭 Generator（ジェネレーター）: プランナーが作成したMarkdown形式のテスト計画を受け取り、それを基に、実際に実行可能なPlaywrightのテストコードを自動的に生成します。Webページのボタンや入力フォームなどの要素を正しく識別し、期待される動作を検証するコードを効率的に作り出してくれます。これにより、手作業でテストコードを一から書く時間を大幅に短縮できます。 🎭 Healer（ヒーラー）: WebアプリケーションのUI変更などでテストコードが動かなくなった場合、このエージェントが活躍します。ヒーラーは、失敗したテストを自動で検知し、その原因を分析します。そして、例えばUI要素の指定（セレクタ）が変わっていた場合に新しいセレクタを提案したり、処理の待機時間を調整したりするなど、テストを修正するための「パッチ」を自動で適用しようとします。これにより、テストのメンテナンス作業が非常に楽になります。 これらのエージェントは、それぞれ単独で使うこともできますが、順番に連携させて使うことで、アプリケーション全体に対する包括的なテストカバレッジ（網羅性）を自動的に生み出すことができます。 導入も簡単で、npx playwright init-agentsというコマンド一つで、プロジェクトにエージェントの定義を追加できます。その後は、VS CodeなどのAIツールと連携して、これらのエージェントに指示を出し、Playwrightテストの作成や修復を自動で行わせることが可能になります。 Playwright Agentは、テスト作成の初期段階からメンテナンスまで、テスト工程全体の効率化を強力にサポートし、エンジニアがより本質的な開発作業に集中できるようにするための画期的な機能と言えるでしょう。 引用元: https://playwright.dev/docs/test-agents エージェント機能が大幅に強化されたPLaMo 2.1 Primeの提供開始 - 株式会社Preferred Networks 皆さん、こんにちは！今回は、国内のAI技術をリードする株式会社Preferred Networks（PFN）から発表された、日本のエンジニアにとって注目のニュースをご紹介します。PFNが独自に開発している国産の大規模言語モデル（LLM）「PLaMo™（プラモ）」の商用版「PLaMo 2.1 Prime」がリリースされ、特に「エージェント機能」が大きくパワーアップしたとのことです。 エージェント機能とは、AIが単に質問に答えるだけでなく、まるで秘書のように、ユーザーの指示を理解して、必要な情報を自動で探し出し、様々なシステムと連携してタスクをこなしてくれる機能のことです。 今回の「PLaMo 2.1 Prime」で特に注目すべきは、「自動ツール連携」機能が実装された点です。これまでのPLaMoも外部システムと連携できましたが、2.1 Primeでは、ユーザーの指示に合う最適なツール（たとえば、Web検索、社内のデータベース、外部のAIエージェント、APIなど）をPLaMoが自分で判断して選び、複数組み合わせて使うことができるようになりました。これにより、AIがより複雑で高度な仕事をこなせるようになります。 例えば、具体的な活用イメージとして以下が挙げられています。 お客様からの問い合わせに対して、PLaMoが「顧客管理システム」で情報を確認し、「在庫管理システム」で在庫状況を調べて、それらの情報をまとめてお客様に回答するといった、複数の情報を連携させた高度な対応が可能になります。 特定のキャンペーンに興味を持ちそうな顧客を社内システムから自動で抽出し、その顧客向けにパーソナライズされたメールの本文をPLaMoが生成、さらにそのメールを自動で送信するといった一連の業務を任せることもできるようになります。 このような自動ツールの選択や呼び出しの精度は、専門のベンチマークテスト「BFCL V3」でも高い評価を得ています。これは、PLaMoがユーザーの意図を正確に汲み取り、必要な情報を適切な方法で引き出す能力が大きく向上したことを意味します。他の大規模言語モデルと比較しても、特定のツール呼び出し能力においてはPLaMo 2.1 Primeが優れている場面があるというのは、国産LLMの大きな進化を感じさせますね。 PLaMoは、PFNが日本語データを使って一から開発した、日本語の扱いに特に長けたLLMです。PLaMo Primeの他にも、自動車などのエッジデバイス向けに軽量化されたPLaMo Liteや、学術・研究用のPLaMo-100B、金融特化型、翻訳特化型など、用途に合わせた様々なモデルが提供されています。今回のアップデートは、PLaMoがさらに多様なビジネスシーンで活躍するための大きな一歩となるでしょう。 国産のAI技術が私たちの仕事や生活をどう変えていくのか、新人エンジニアの皆さんもぜひ注目してみてください！ 引用元: https://www.preferred.jp/ja/news/pr20251007-2/ お便り投稿フォーム （株式会社ずんだもんは架空の登場組織です）