Avsnitt
-
関連リンク AI system development: LLM → RAG → AI Workflow → AI Agent CodeLink
この記事では、AIシステム開発が「LLM」から始まり、「RAG」「AI Workflow」を経て、最終的に「AI Agent」へと段階的に進化していく過程を、新人エンジニアにも分かりやすく解説しています。すべてのAIシステムに高度なAI Agentが必要なわけではなく、解決したい問題に合わせて適切な技術を選ぶことが重要だと述べられています。
まず、Pure LLM（純粋なLLM）は、インターネット上の膨大な情報を学習した知識の塊です。小説の要約や文章作成など、学習データ内の情報を使うタスクは得意ですが、リアルタイムの情報取得や外部ツールとの連携はできません。しかし、プロンプトの工夫（in-context learningなど）で、ある程度の問題解決が可能です。例えば、レジュメが職務要件に合うかを分類するような単純なタスクなら、LLM単体でも対応できます。
次に、RAG (Retrieval Augmented Generation)は、LLMに外部の関連情報を与えることで、より正確で最新の回答を生成させる手法です。これにより、LLMは企業の内部データや最新のリアルタイム情報も活用できるようになります。レジュメスクリーニングの例では、社内の技術マニュアルや過去のレジュメを参考にして、より適切な判断ができるようになります。この際、ベクトルデータベースやセマンティック検索といった技術が使われます。
さらに進んだ段階が、Tool Use & AI Workflow（ツール利用とAIワークフロー）です。これは、LLMが電卓やメールサービス、検索エンジンといった外部ツール（API）と連携し、定められた手順に沿ってビジネスプロセスを自動化する仕組みです。定型的なタスク、例えばレジュメの取得、内容評価、そして合否通知メールの送信といった一連の流れを自動化できます。LLMはデータベースやメールAPI、カレンダーAPIなどにアクセスして、プログラムされた手順を実行します。
そして、最も進化した形がAI Agent（AIエージェント）です。AIエージェントは、タスクを自律的に分解し、必要なツールを判断して使い、結果を評価し、次に何をすべきかを自分で決められるシステムです。AIワークフローが決められた手順をなぞるのに対し、AIエージェントは自分で計画を立て、状況に応じて動的に手順を決定・実行します。採用プロセス全体（CV解析、面接調整、スケジュール変更対応など）を、人間がほとんど介入せずに自動で管理するような複雑なタスクをこなすことができます。
この記事の重要なポイントは二つです。一つは、「すべてのシステムにAIエージェントが必要なわけではない」ということ。シンプルな構成から始め、必要に応じて複雑な機能を追加していくのが賢明です。もう一つは、「機能よりも信頼性を重視すべき」という点。LLMは非決定的な性質があるため、本番環境で安定稼働させるには、綿密なテストと安全対策（ガードレール）が不可欠です。新人エンジニアの皆さんも、この段階的な進化と重要ポイントを理解して、AIシステム開発に取り組んでいきましょう。
引用元: https://www.codelink.io/blog/post/ai-system-development-llm-rag-ai-workflow-agent
How Early Access to NVIDIA GB200 Systems Helped LMArena Build a Model to Evaluate LLMsこんにちは、新人エンジニアの皆さん！今回ご紹介する記事は、私たちが普段利用する大規模言語モデル（LLM）の「どれが、どんなタスクに一番得意なのか」を賢く評価する新しいシステムと、その裏側にある最新技術のお話です。
カリフォルニア大学バークレー校のLMArenaが開発した「P2L（Prompt-to-Leaderboard）」モデルは、LLMの得意分野を見極めるための画期的なツールです。これまでのLLM評価は総合スコアで示されることが多かったのですが、P2Lは「数学ならこのモデル、プログラミングならあのモデル」といったように、特定のタスク（例えば、数学、コーディング、創造的ライティングなど）ごとに、どのLLMが優れているかを人間の評価（投票）を基に判断します。これにより、単一のランキングでは見えにくいLLMごとの「個性」や「得意技」がはっきり分かるようになります。さらに、予算に応じて最適なモデルを自動で選ぶ「コストベースのルーティング」もできるので、利用コストを抑えながら最高のパフォーマンスを引き出すことも可能です。
このP2Lモデルの開発と、それを実際に動かすための大規模なシステム構築を強力に支えたのが、NVIDIAの最新AIスーパーコンピュータ「GB200 NVL72」の早期アクセスでした。LMArenaは、NVIDIA DGX CloudとNebius AI Cloudを通じてこの高性能システムを利用。GB200 NVL72は、多数の高性能CPUとGPUを高速で接続した、まさにAIのためのモンスターマシンです。このおかげで、P2Lモデルの複雑な学習プロセスをわずか4日間で完了させるなど、従来のシステムに比べて圧倒的なスピードアップを実現しました。
NVIDIAとNebiusは、P2Lの開発チームが本質的な開発に集中できるよう、手厚いサポートを提供しました。具体的には、GB200 NVL72上でPyTorchやHugging Face Transformersといった主要なオープンソースAIフレームワークが問題なく、そして最高のパフォーマンスで動作するように事前に検証・最適化してくれたのです。これにより、LMArenaのエンジニアは、インフラの構築やツールの互換性といった煩雑な作業に時間を取られることなく、P2Lの機能向上に全力を注ぐことができました。
このLMArena、NVIDIA、Nebiusの協力事例は、最新の高性能AIハードウェアと、それを最大限に活用するためのクラウド環境、そして革新的なAI評価モデルが一体となることで、AI開発がいかに加速するかを私たちに示しています。AIモデルの種類が爆発的に増え続ける現代において、どのAIを、どんなタスクに、どのくらいのコストで使うべきかを効率的に見極めるP2Lのようなシステムは、これからのAI開発を大きく前進させる鍵となるでしょう。皆さんが今後AIを扱う上で、モデルの選び方や評価の重要性を理解する上での良いヒントになるはずです。
引用元: https://developer.nvidia.com/blog/how-early-access-to-nvidia-gb200-systems-helped-lmarena-build-a-model-to-evaluate-llms/
オープンソースのAI開発エージェント基盤にコマンドライン版「OpenHands CLI」が登場 gihyo.jp新人エンジニアの皆さん、こんにちは！プログラミングの世界に新しい風を吹き込む exciting なニュースです。「OpenHands」というオープンソースのAIソフトウェア開発エージェントに、コマンドライン版「OpenHands CLI」がリリースされました。これは、AIが皆さんのプログラミング作業をグッと楽にしてくれる可能性を秘めたツールなんです。
まず、「OpenHands」について簡単に説明しますね。これは、AIがまるで優秀なアシスタントのように、皆さんの指示（自然言語、つまり普段使う言葉）を理解して、プログラミングのコードを書いたり、プログラムのミス（バグ）を見つけて直したり、ファイルを操作したり、必要なコマンドを実行したり、さらにプログラム同士を連携させる「API」の呼び出し、テスト、コードの整理（リファクタリング）まで、さまざまな開発作業を自律的に行ってくれるプラットフォームです。オープンソースなので、誰でも自由に利用したり、その中身を見て改良したりできます。
今回リリースされた「OpenHands CLI」は、このOpenHandsを、普段エンジニアがよく使う「ターミナル」（黒い画面に文字を打ち込んで操作する場所）から直接利用できるようにしたものです。これまでのOpenHandsはGUI（グラフィカルな画面でマウス操作する方式）が中心でしたが、CLI版の登場にはいくつかの大きなメリットがあります。
一番のポイントは、ローカル環境にインストールする際に「Docker」という仮想環境を作るツールが不要になったことです。Dockerは便利なツールですが、導入に少し手間がかかる場合もあります。それが不要になることで、OpenHandsを試したいと思ったときに、もっと手軽に始められるようになりました。また、GUIが必要ないので、リモートのサーバーや皆さんが普段使っている「IDE」（統合開発環境、コードを書くための高機能なエディタのようなもの）など、慣れた開発環境で直接AIエージェントの力を借りて作業ができるようになります。
さらに、コマンドライン操作ならではの「軽快な動作」と「パフォーマンスの向上」も期待できます。キーボードだけでサクサク操作できる「スラッシュコマンド」なども用意されていて、普段からコマンドライン操作に慣れているエンジニアにとっては、非常に使いやすいツールになっているでしょう。
OpenHands CLIを使うためには、Python 3.12または3.13がインストールされていれば、pipコマンド一つで簡単に導入できます。利用するAIモデルについても柔軟で、特定のAIモデル（LLMプロバイダ）に依存せず、さまざまなクラウドベースやローカルで動くLLMを利用できます。記事によると、現時点ではClaude 4 sonnetがクラウドベースで最高のパフォーマンスを発揮しているとのことです。また、ローカルで動かすモデルとしては、ソフトウェア開発に特化した「Devstral」というモデルも推奨されています。
このようにOpenHands CLIは、AIを開発プロセスに組み込むことをより身近で効率的なものにしてくれます。新人エンジニアの皆さんも、ぜひこの新しいツールに触れてみて、AIがどのように開発を助けてくれるのかを体験してみてください。きっと、皆さんの開発効率を大きく向上させてくれるはずです。
引用元: https://gihyo.jp/article/2025/06/openhands-cli
【ずんだもん】新作ぬいぐるみ2種が登場。ぶるぶる震えたり大きかったり…両方ほしくなるのだ！人気のAIキャラクター「ずんだもん」から、新作のプライズぬいぐるみが2種類登場しました！一つは紐を引っ張るとぶるぶる震える「ぶるぶるぬいぐるみ」（全4種、約15cm高）で、もう一つは表情豊かな約30cmのビッグサイズ「デフォルメぬいぐるみ」（全2種）です。どちらもオンラインクレーンゲームなどで手に入ります。日々の開発の合間に、かわいいずんだもんに癒されてみてはいかがでしょうか？
引用元: http://news.dengeki.com/article/202506/45265
お便り投稿フォームVOICEVOX:ずんだもん
-
関連リンク 【Claude Code Tips】私のマイCLAUDE.mdを解説します
この記事では、ターミナルで動作するAIコーディングツール「Claude Code」をより効果的に使うための設定ファイル「CLAUDE.md」について、具体的な設定例を交えながら解説されています。新人エンジニアの方も、AIを活用した開発のヒントとして役立つでしょう。
CLAUDE.mdは、Claude Codeにプロジェクト固有の知識を覚えさせる「メモリ機能」です。これにプロジェクトの設計やコーディングルール、作業の流れなどを記述することで、AIが生成するコードの質を上げることができます。たくさん書きすぎるとAIが内容を無視してしまうことがあるため、必要な情報を簡潔にまとめることが大切です。英語で書く方がAIが処理しやすい（トークン量を抑えられる）側面もありますが、筆者は保守性を考慮して日本語で書くことも問題ないとしています。
筆者のCLAUDE.mdには、開発中のSNSアプリ「Gotoshisha」の具体的な情報が記述されています。
プロジェクト概要: アプリの目的や主な機能。 技術スタック: 利用しているプログラミング言語、フレームワーク、クラウドサービスなど。 プロジェクト構造: ディレクトリの構成。 開発ワークフロー: 環境構築や開発開始の手順。 テストガイドラインとコード生成規約: テストの書き方（Vitestを使い、テストコードを実装ファイルと同じ場所に書く、日本語でテスト説明を書くなど）や、コードの書き方のルール（コメントの付け方、ハードコードを避けるなど）。特に注目すべきは、テストガイドラインの重要性です。AIにコードを生成させる際、テスト駆動開発（先にテストを書き、それに合わせてコードを開発する手法）と組み合わせることで、AIが作ったコードが正しく動くかを確認しやすくなり、スムーズに開発を進められると筆者は強調しています。
また、Claude Codeが実行できるコマンドを細かく設定する.claude/settings.jsonファイルについても紹介されています。このファイルで、AIに自動で許可するコマンド（allowリスト）と、絶対に禁止するコマンド（denyリスト）を設定することで、安全にAIと協力して開発を進めることができます。
まとめると、CLAUDE.mdにプロジェクトの情報を詳しく、かつ簡潔に記述し、特にテスト駆動開発と組み合わせることで、Claude Codeの能力を最大限に引き出し、効率的で品質の高い開発ができるという点がこの記事の大きな学びです。
引用元: https://zenn.dev/dirtyman/articles/ddbec05fd9fbb4
Benchmarking LLM Inference Costs for Smarter Scaling and Deploymentこの記事は、大規模言語モデル（LLM）の運用にかかるコスト（推論コスト）を効率的に見積もり、賢くシステムを拡張・展開するための方法を、新人エンジニアにも分かりやすく解説しています。LLMが様々なアプリケーションの基盤となる中で、システムを大規模に運用する際には、どれくらいのインフラが必要で、総費用（TCO: Total Cost of Ownership）がどれくらいになるかを事前に把握することが非常に重要になります。
このブログ記事では、主に以下の3つのステップを通じて、LLMの推論コストを計算する流れを説明しています。
パフォーマンスベンチマークの実施:まず、LLMを動かすサーバーが、どれくらいの速さでどれだけの処理量（スループット）をこなせるのか、そして応答にどれくらいの時間（レイテンシ）がかかるのかを測定します。これは、必要なハードウェアの規模を決めるための土台となります。NVIDIAの「GenAI-Perf」のようなツールを使うと、「最初の単語が出るまでの時間（TTFT）」や「1秒あたりのリクエスト数（RPS）」といった主要な性能指標を測ることができます。これは、チャットボットのようにリアルタイム性が求められるシステムでは特に重要です。
ベンチマークデータの分析と最適な構成の特定:測定したデータから、システムが最高の性能を発揮できるバランス点を見つけます。一般的に、多くのリクエストを同時に処理しようとするとスループットは上がりますが、個々の応答にかかる時間は長くなる傾向があります（レイテンシが増える）。このトレードオフを理解し、例えば「応答時間は250ミリ秒以内」といった要件を満たしつつ、最も効率よく処理できる設定（パレート最適フロンティア）を選び出します。これにより、「ピーク時にこれだけの要求を処理するには、最低限これだけの数のLLMインスタンス（処理単位）が必要だ」という具体的な数字を算出できます。
総所有コスト（TCO）の計算:最後に、算出した必要なインフラに基づいて、実際にどのくらいの費用がかかるのかを計算します。これには、サーバーやGPUといった「ハードウェア費用」、LLMのソフトウェアを使うための「ライセンス費用」、サーバーの「ホスティング費用」などが含まれます。これらの費用を組み合わせ、「必要なサーバー台数」や「年間にかかる総費用」を算出します。さらに、「1000回の問い合わせ（プロンプト）あたりにかかる費用」や「100万トークン処理あたりにかかる費用」といった、より具体的な運用コストも計算できるようになります。
これらのステップを踏むことで、LLMアプリケーションを大規模に展開する前に、コスト面での計画をしっかりと立て、効率的で費用対効果の高いシステムを構築するための重要な知見が得られます。新人エンジニアの皆さんも、将来的にAIシステムを設計・運用する際に、このようなコストの見積もり能力が非常に役立つでしょう。
引用元: https://developer.nvidia.com/blog/benchmarking-llm-inference-costs-for-smarter-scaling-and-deployment/
医療AI診断の盲点：GPT-4o・Command R+を人間が使うと精度が3分の1に低下、1,298人実験で判明 - イノベトピア今回ご紹介するオックスフォード大学の研究は、大規模言語モデル（LLM）を使った医療診断において、「人間が関わることでAIの診断精度が大きく低下する」という、新人エンジニアの皆さんがAIシステム開発を考える上で非常に重要な研究結果です。
LLMとは、ChatGPTなどで使われる、大量のテキストから学習し自然な文章を理解・生成できるAIモデルのことです。この研究では、GPT-4oやLlama 3、Command R+といった最新のLLMを使って、1,298人の参加者に医療シナリオの診断実験を行いました。
結果は驚くべきものでした。LLMが単独で病状を特定する精度は94.9%と非常に高かったのに対し、人間がLLMを使って診断を行った場合、正答率は34.5%以下にまで落ち込んでしまったのです。これは、従来の自己診断方法よりも低い結果でした。
なぜこのようなギャップが生じたのでしょうか？研究では、参加者がLLMに症状を伝える際に情報が不完全だったり、LLMからの回答を人間が誤解したりする問題が確認されました。例えば、重要な情報を省略して伝えたために、LLMが誤った診断を下すケースが見られました。つまり、AIがどんなに高性能でも、人間がAIにどう情報を与えるか（プロンプトの質）、そしてAIからの情報を人間がどう解釈するかが、そのAIの最終的な性能を大きく左右するということです。
この課題は医療分野に限らず、AIチャットボットを使ったカスタマーサポートなど、人間とAIが相互作用するあらゆるシステムに共通します。システム開発においては、「テスト環境では完璧に見えたAIが、実際のユーザーに使われると期待通りの性能を出せない」というリスクがあることを理解しておく必要があります。
AIが真に役立つシステムとなるためには、単にAIモデルの性能を高めるだけでなく、「人間が質の高いプロンプトを与えやすい工夫」や、「AIからの情報を人間が正しく理解できるように、AIの回答を分かりやすく提示する工夫」といった、「人間とAIのコミュニケーション」を円滑にする設計が非常に重要です。
また、興味深いことに、AI同士で診断実験を行った場合は60.7%の正答率を示しました。これは、人間とAIの組み合わせよりもAI同士の方が効率的に情報をやり取りできる可能性を示唆しています。
新人エンジニアの皆さんがAI開発に携わる際、「技術は素晴らしいけれど、実際に使うのは人間だ」という視点を常に持ち、人間の認知特性や行動パターンを深く理解し、それに適応する「人間中心のAI設計」を心がけることが、真に価値あるAIシステムを生み出す鍵となるでしょう。
引用元: https://innovatopia.jp/ai/ai-news/57656/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
Saknas det avsnitt?
-
関連リンク Building Effective AI Agents
Anthropicは、LLM（大規模言語モデル）エージェント構築の経験から、効果的なAIエージェントを作るためのヒントを共有しています。多くの成功事例では、複雑なフレームワークよりも、シンプルで組み合わせやすいパターンが使われていることが分かりました。
エージェント的システムとは「エージェント」には様々な定義がありますが、AnthropicではLLMとツールを組み合わせたシステム全体を「Agentic systems（エージェント的システム）」と呼んでいます。その中で、特に重要な2つのタイプを区別しています。
Workflows（ワークフロー）: 事前に決められた手順（コードパス）に沿ってLLMとツールを動かすシステムです。 Agents（エージェント）: LLM自身がタスクの進め方やツールの使い方を、状況に応じて動的に判断し、制御するシステムです。エージェントを使うべきケースとそうでないケースLLMアプリケーションを作る際は、まず最もシンプルな方法から試し、本当に必要になった場合にだけ複雑なシステムを導入することが推奨されます。エージェント的システムは、より良いタスク性能を目指す一方で、処理が遅くなったり、コストがかさんだりするトレードオフがあるため、そのバランスを考える必要があります。
ワークフローは、手順が明確で、予測可能で安定した動作が必要なタスクに適しています。 エージェントは、タスクが複雑で、柔軟性やLLM自身が判断を下す能力が大規模に求められる場合に有効です。しかし、多くのケースでは、LLMへの一度の問い合わせを最適化するだけで十分な結果が得られることもあります。
フレームワークの活用についてLangGraphやAmazon BedrockのAI Agentフレームワークなど、エージェントシステムの開発を助けるツールが多数存在します。これらは、LLMの呼び出しやツールの定義、処理の連携といった基本的な作業を簡単にしてくれます。
一方で、フレームワークを使うと、抽象化の層が増えることで、内部のプロンプトやLLMの応答が見えにくくなり、デバッグが難しくなることがあります。また、シンプルな方法で済む場合でも、不必要に複雑なシステムを作り上げてしまう誘惑に駆られることもあります。
Anthropicは、まずLLMのAPIを直接使ってみることを推奨しています。多くのパターンは簡単なコードで実現できます。もしフレームワークを使う場合は、その内部の仕組みをしっかりと理解しておくことが重要です。
まとめと開発の原則LLMを使った開発において最も大切なのは、凝ったシステムを作ることではなく、自分のニーズに「最適なシステム」を構築することです。まずはシンプルなプロンプトから始め、性能を評価しながら改善を進め、もしシンプルな解決策では対応できない場合にのみ、より複雑な多段階エージェントシステムを導入しましょう。
エージェントを開発する際には、以下の3つの重要な原則を意識することが推奨されています。
シンプルさ: エージェントの設計は、できるだけ簡潔に保つことが成功の鍵です。 透明性: エージェントが次に何をしようとしているか、その計画のプロセスを明確に示せるようにしましょう。 注意深いACI (Agent-Computer Interface) 設計: エージェントが使うツールの使い方や役割を丁寧に文書化し、入念にテストすることで、エージェントとコンピューターの間の連携を最適化しましょう。フレームワークは開発のスタートを加速させますが、システムを本番環境で運用する際には、抽象化を減らして、基本的なコンポーネントで構築することも検討してください。これらの原則に従うことで、強力であると同時に信頼性が高く、メンテナンスしやすいエージェントを作り出すことができるでしょう。
引用元: https://www.anthropic.com/engineering/building-effective-agents
How to think about agent frameworksAIの進化により「AIエージェント」が注目されていますが、実用的なエージェントシステムを開発するのは簡単ではありません。この記事では、信頼性の高いエージェントを構築するための考え方と、フレームワークの選び方について解説しています。
1. AIエージェントとワークフローの区別「AIエージェント」という言葉には様々な解釈がありますが、Anthropic社は「ワークフロー」と「エージェント」を区別しています。
ワークフロー: LLM（大規模言語モデル）とツールが、事前に決められた手順（コード）に沿って動くシステムです。動きが予測しやすく、安定しています。 エージェント: LLM自身が状況を判断し、動的にツールを選び、タスクを遂行するシステムです。より柔軟ですが、その分予測が難しいことがあります。実際の多くのAIシステムは、これらの「ワークフロー」と「エージェント」を組み合わせて作られています。単純で予測可能なタスクにはワークフロー、複雑で柔軟な判断が必要なタスクにはエージェントというように、それぞれの特性を理解して使い分けることが重要です。2. 信頼性の高いエージェント構築の鍵プロトタイプは簡単に作れても、ビジネスで使える信頼性の高いエージェントを作るのは非常に難しいです。一番の課題は、「LLMに適切な『コンテキスト』（文脈や情報）を、各ステップで正しく与えること」です。LLMが意図しない動作をする主な原因は、必要な情報が不足していたり、情報の形式が悪かったりすることにあります。そのため、開発する際には、LLMに渡すコンテキストを細かく制御できるかどうかが極めて重要になります。
3. エージェントフレームワークの役割とLangGraph多くのエージェントフレームワークは、開発を簡単に始めるための「エージェント抽象化」という機能を提供します。これは手軽な反面、内部の動作やLLMへのコンテキスト制御が見えにくくなるデメリットもあります。LangGraphは、こうした課題を解決するために設計された「オーケストレーションフレームワーク」です。これは、システム全体の流れを管理・調整する役割を担います。
柔軟な設計: 宣言的なグラフ構造でシステムの流れを定義しつつ、各処理（ノード）の中身は通常のコードで書けるため、手軽さと高い制御性を両立しています。ワークフローとエージェントの両方のパターンに対応できます。 豊富な機能: 記憶機能: 会話の履歴を保持する短期記憶や、長期的な学習を可能にする機能。 人間との協調: エージェントの途中に人間の承認を挟んだり、実行後に動作を検証・修正したりする機能。 リアルタイム更新: 処理の進捗をユーザーに即座に伝えるストリーミング機能。 デバッグ・監視: LLMの入出力を詳細に確認し、問題を特定するためのツール（LangSmithなど）との連携。 耐障害性: 途中でエラーが発生してもシステムが停止しないような仕組み。これらの機能は、エージェントだけでなくワークフロー型のシステムでも大いに役立ち、開発者がより信頼性の高いアプリケーションを構築するのを助けます。4. まとめ今後のLLMの性能がさらに向上したとしても、LLMに与えるコンテキストを適切に制御する重要性は変わりません。実用的なAIシステムは、多くの場合、ワークフローとエージェントの最適な組み合わせから生まれます。LangGraphのようなフレームワークは、開発の初期段階だけでなく、長期的に見て信頼性、保守性、拡張性のあるAIシステムを構築するために不可欠なツールとなるでしょう。
引用元: https://blog.langchain.com/how-to-think-about-agent-frameworks/
We’re expanding our Gemini 2.5 family of modelsGoogleは、AIモデル「Gemini 2.5」ファミリーのラインナップをさらに強化し、開発者がより柔軟にAIを活用できるよう新しいモデルの提供を開始しました。
まず、これまでプレビュー版として提供されてきた「Gemini 2.5 Flash」と「Gemini 2.5 Pro」が、正式に「一般提供（GA: Generally Available）」となりました。これは、これらのモデルが安定し、実際のサービスや製品に組み込んで使うのに適したレベルになったことを意味します。すでにSplineやRooms、Snap、SmartBearといった企業がこれらのモデルを本番環境で利用しており、その信頼性が証明されています。新人エンジニアの皆さんも、これらのモデルを使って、より本格的なAIアプリケーション開発に安心して取り組めるようになります。
そして、新たに「Gemini 2.5 Flash-Lite」のプレビュー版が公開されました。このモデルは、Gemini 2.5ファミリーの中で「最もコスト効率が良く、最も高速」という特徴を持っています。AIモデルの利用にかかる費用を抑えつつ、素早い応答が必要なタスクに特に強みを発揮します。例えば、大量のテキストを翻訳したり、情報を分類したりするような処理で、これまで以上に効率的なAI活用が期待できます。
Flash-Liteは、これまでの2.0世代のモデルと比較しても、コーディング、数学、科学、推論、さらにはテキスト以外の情報（画像や音声など）を扱うマルチモーダルな能力においても、全体的に高い品質を実現しています。また、Gemini 2.5シリーズの大きな特徴である「100万トークン」という非常に長い文章や大量の情報を一度に処理できる能力や、Google検索やコード実行といった外部ツールと連携できる機能も、Flash-Liteでそのまま利用できます。これにより、より複雑で実用的なAIシステムを構築できるようになります。
これらの新しいモデルは、Google AI StudioやVertex AIといったGoogleのAI開発プラットフォームを通じてすぐに利用を開始できます。また、Gemini 2.5 FlashとProは、Geminiアプリからも利用可能です。さらに、Google検索の一部にもカスタムバージョンのFlash-LiteとFlashが導入されており、私たちの日常生活にもAIの恩恵が広がっています。
今回の発表は、AI開発の選択肢を広げ、さまざまな用途に応じた最適なモデルを選べるようになることを示しています。新人エンジニアの皆さんにとって、最先端のAI技術に触れ、新しい価値を創造する大きなチャンスとなるでしょう。
引用元: https://deepmind.google/discover/blog/were-expanding-our-gemini-25-family-of-models/
四国めたんのプラモデルにミニフィギュア同梱版が登場！6月19日（木）10時より予約開始！PLUM WEB SHOP限定でミニフィギュアの単品販売も！ 電撃ホビーウェブ人気キャラクター「四国めたん」の全身可動プラモデルに、新しく作られたミニフィギュアが同梱された特別版が登場します。2025年6月19日(木)午前10時から予約が始まります。このプラモデルは色々なポーズが取れるので、飾って楽しめますよ。ミニフィギュアはPLUM WEB SHOPで単品でも買えるそうです。ホビーに興味がある新人エンジニアの方は、ぜひチェックしてみてくださいね。
引用元: https://hobby.dengeki.com/news/2633689/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Metas Llama 3.1 can recall 42 percent of the first Harry Potter book
AIモデルの著作権侵害訴訟が増える中、Meta社の主要LLMであるLlama 3.1の「記憶」能力に関する興味深い研究が注目されています。これは「AIモデルが元の学習データをそのまま出力してしまうことがあるのか？」という問題に深く関わっています。
スタンフォード大学などの研究チームが、Llama 3.1 70Bモデルを含むいくつかのモデルを調査したところ、驚くべき結果が発表されました。研究によると、Llama 3.1 70Bは『ハリー・ポッターと賢者の石』の最初の本のおよそ42%を、元の文章そのままに再現する能力があることが分かりました。これは、モデルが書籍の内容を高い精度で「記憶」していることを示唆しています。Llama 1 65Bが同じ本をわずか4.4%しか記憶していなかったのと比較すると、Llama 3.1ではその記憶能力が大幅に向上しています。また、人気のある書籍（例：『ホビット』や『1984年』など）ほど、Llama 3.1が内容を記憶している傾向があることも分かりました。
では、どのようにモデルの記憶能力を測ったのでしょうか？研究者たちは、モデルが次にどのような「単語の断片」（トークン）を生成するか、その確率を計算する手法を用いました。この確率を繋ぎ合わせることで、50個のトークンが特定の文章とどれくらい一致するかを、実際にモデルに生成させずに推定することが可能になりました。これにより、非常に少ない確率でしか出ないような特定の文章も効率的に分析できるようになりました。
この研究結果は、著作権訴訟に大きな影響を与える可能性があります。AI企業はこれまで「モデルは単に言葉のパターンを学習するだけで、元のデータをコピーするわけではない」と主張してきましたが、Llama 3.1が書籍の大部分を再現できる事実は、この主張を困難にします。特に、「フェアユース」（公正利用）という著作権の考え方にも影響が出そうです。Google Booksの事例では、書籍からごく一部しか出力しない点がフェアユースと認められましたが、Llama 3.1はより多くの部分を再現できるため、議論が複雑化します。
さらに、Llamaのようにモデルの内部構造（重み）を公開している「オープンウェイトモデル」が、そうでない「クローズドウェイトモデル」に比べて、法的に不利になる可能性も指摘されています。オープンウェイトモデルでは、今回の研究のように内部の挙動を詳しく分析できるため、著作権侵害の証拠が見つかりやすいためです。これはAI開発のオープンな共有を阻害する可能性があり、今後の業界動向に注目が集まります。この研究は、AI技術の発展と著作権保護のバランスについて、重要な示唆を与えています。
引用元: https://www.understandingai.org/p/metas-llama-31-can-recall-42-percent
プライドも、サンクコストも捨てろ「健康診断」しないエンジニアは死滅する - エンジニアtype 転職typeVR開発者であるナル先生こと近藤義仁氏が、AIの発展がエンジニアのキャリアにどう影響するかについて語っています。
AI時代において、ソフトウェアエンジニアの仕事が完全になくなるわけではありませんが、その役割は大きく変化するとナル先生は指摘します。特にAIを導入しにくい一部の業界では人間エンジニアが残り、Web系の分野ではAIによる代替が進むでしょう。AIの能力は急速に進化しており、かつてのような「職人気質」でプライドが高く、人間関係が難しいタイプのエンジニアは、AIの圧倒的なスピードと人間的な特性を兼ね備えた人材に取って代わられる可能性があります。
この変化の時代を生き抜くために最も重要なのは、「プライド」や「これまでの投資（サンクコスト）」を捨てて、新しい技術、特にAIを常に学び続ける姿勢だとナル先生は強調します。AIの進化は非常に速く、数年前の常識はあっという間に通用しなくなるため、毎日AIの最新ツールや機能を触り、その動向をチェックする「技術的な健康診断」が不可欠です。ナル先生自身も、朝4時に起きてX（旧Twitter）でAI情報を収集・発信し、将来的には自身のXログを学習させたローカルLLMを動かすことで「自分年金」を構築する計画を語っています。
今後は、AIエージェントを大量に束ねて指示できる「オーケストレーション」能力を持つ人材が非常に価値を持つ時代になります。また、AIが物理的な作業など、自身ではできないことを人間に指示する「HaaS（Human as a Service）」という働き方も登場するかもしれません。これは、組織に属する従来のサラリーマンという概念が崩壊し、個人のスキルと「役割」が重要になる、より多様で自由な働き方が広がる「ユートピア」な未来を示すとナル先生は語ります。
労働がAIに代替されることで、人間は「やりたくないこと」から解放され、余暇が増え、よりクリエイティブな活動に集中できるようになるでしょう。この変化に適応し、常に新しいものに触れ、柔軟な考え方を持つことが、これからのエンジニアにとって最も大切な資質となります。
引用元: https://type.jp/et/feature/28625/
Groq on Hugging Face Inference Providers 🔥Hugging Faceが、AIモデルの超高速推論を提供する「Groq（グロック）」を公式のインファレンスプロバイダーとして追加しました。これは、AIモデルを動かす（推論する）際に、より多様で高性能な選択肢が増えたことを意味し、特に大規模言語モデル（LLM）を使う開発者にとって朗報です。
Groqの最大の強みは、彼らが独自に開発した「LPU™（Language Processing Unit）」というプロセッサです。これは、LLMのような計算量の多い処理を高速に、そして低遅延で実行するために特化して設計されています。一般的なGPU（グラフィックボード）では苦手とする、連続した処理の速さに優れており、リアルタイム性が求められるAIアプリケーションに特に適しています。例えば、チャットボットのように「すぐに返答が欲しい」場面で、その真価を発揮します。
今回の連携により、Hugging Face Hubで提供されている多くのオープンソースLLM（MetaのLLama 4やQwenのQwQ-32Bなど）を、GroqのLPUの速度で手軽に利用できるようになりました。これは、モデルの性能を最大限に引き出しつつ、応答速度が重要なアプリケーションを開発する際に非常に役立ちます。
Hugging Face Hub上での利用はとても簡単です。ウェブサイトのUIから、またはPythonやJavaScriptのSDK（開発キット）を使って、Groqの推論APIを利用できます。ユーザーは自分のGroq APIキーを使う「カスタムキー」方式か、Hugging Face経由で認証・課金を行う「Hugging Faceルーティング」方式のどちらかを選べます。Hugging Faceルーティングの場合、追加料金なしでプロバイダーの標準料金のみが適用され、Hugging FaceのPROユーザーには毎月無料のインファレンスクレジットも提供されます。
この連携により、新人エンジニアの方々も、最先端の高速AI推論インフラをより身近に感じ、多様なAIモデルの活用や新たなアプリケーション開発に挑戦しやすくなるでしょう。推論速度はユーザー体験に直結するため、今回のGroqとの連携は、より良いAIサービスを生み出すための重要な一歩と言えます。
引用元: https://huggingface.co/blog/inference-providers-groq
「ずんだもん」から生まれた派生キャラクター「ずんだどん」1/12可動フィギュア化が決定。衣装は布製。めしを喰うでごわす！！人気キャラクター「ずんだもん」の派生キャラ「ずんだどん」の1/12スケール可動フィギュア化が決定しました。この「ずんだどん」は、「ずんだもん」に関するユニークな嘘投稿から誕生した異色のキャラクターです。本来のずんだもんとは異なる巨漢のビジュアルが特徴で、今回の立体化は関係者の許諾を得て実現しました。衣装は布製で、現在監修中。完成が待ち遠しいですね！
引用元: https://news.denfaminicogamer.jp/news/250616o
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Anthropic「How we built our multi-agent research system」の要点まとめ
Anthropicが、AIの「マルチエージェントシステム」をどう作ったか、その開発の裏側と重要な知見を公開しました。これは、AIアシスタント「Claude」の調査機能（Research機能）を開発する中で得られた貴重な学びです。
AnthropicのResearch機能は、「オーケストレーター・ワーカーパターン」という仕組みを使っています。これは、一人の「リーダーエージェント」がユーザーの質問を受け、それをいくつかの小さなタスクに分解します。分解されたタスクは、複数の「サブエージェント」（リサーチャーエージェント）に指示され、それぞれが並行して調査を行います。最後に、リーダーエージェントが各サブエージェントの結果を統合し、最終的な回答を作成するという流れです。まるで、プロジェクトリーダーが専門チームに仕事を割り振り、最後にまとめて報告書を作るようなイメージです。
このマルチエージェントシステムは、得意なことと苦手なことがあります。得意なのは、たくさんの調査を同時に進める「並列処理」や、大量の情報を扱うタスク、複数のツールを使う作業です。実際に、シングルエージェント（一人のAI）よりも高い調査性能を発揮しました。一方、苦手なのは、プログラミングのように並列化しにくい作業や、全員で同じ情報を共有しながら進める必要がある作業です。このシステムの性能を大きく左右するのは、AIがどれだけ「思考」（＝トークン）を使うか、つまりどれだけ深く考える時間を与えられるかです。しかし、大量のトークンを使うため、コストが高くなる点が大きな課題です。最新のモデルに切り替えることで、効率を上げつつコストを最適化できると報告されています。
開発では、AIへの指示文である「プロンプトエンジニアリング」が非常に重要でした。Anthropicは、以下の8つのコツを見つけました。
AIの思考をシミュレーションする: AIが指示をどう解釈し、行動するか想像する。 リーダーエージェントに仕事の振り方を教える: サブエージェントへ目的、形式、ツール、担当範囲を具体的に指示させる。 タスクの規模に応じた人員配置: 簡単な質問には少ないAI、複雑な調査には多くのAIを割り当てる。 ツールの設計と選択: 適切なツールを選ばせ、その使い方を明確に説明する。 エージェントに自己改善させる: AI自身に失敗の原因を診断させ、プロンプトを改善させる。 広く始めてから絞り込む: まず全体像を掴み、徐々に詳細を調べるように指示する。 AIに思考する時間を与える: 作業前に戦略を練ったり、結果が出るたびに立ち止まって考えさせたりする。 並列処理で高速化: 複数のサブエージェントやツールを同時に動かすことで、調査時間を大幅に短縮する。これらの戦略は、厳格なルールではなく、経験からくる良い「やり方」をAIに教え込み、同時に「これはしてはいけない」というガードレールを設定することで実現しました。AIシステムの効果的な評価方法についても紹介されています。
小規模でもすぐに始める: 最初から完璧な評価システムを目指すのではなく、少数のテストケースでも効果は大きい。 LLM-as-judgeを活用する: 生成された回答の正確性や網羅性などを、別のLLM（大規模言語モデル）に評価させる。 人間による評価も不可欠: 自動評価では見落としがちな、AIの不自然な挙動や誤りを人間が見つけ、改善につなげる。マルチエージェントシステムは複雑ですが、適切に設計・運用することで、人間だけでは難しい大規模な調査や分析を可能にする強力なツールとなることが示されています。
引用元: https://zenn.dev/ml_bear/articles/a5dc93b9d03edd
Claude CodeとGitHub Issueを使った全自動開発についてこの記事は、最新のAI技術であるClaude Codeと、ソフトウェア開発で広く使われるGitHub Issueを連携させ、開発プロセスを「全自動化」するコンセプトと、それを実現するためのスクリプトについて紹介しています。これは、AIが自律的にソフトウェア開発のタスクをこなし、まるで一人のエンジニアのようにプロジェクトを進める未来の働き方を垣間見せてくれるものです。
この自動開発システムの基本的な流れはこうです。まず、GitHubリポジトリに登録されている未解決のIssueの中から、スクリプトが優先度（P0, P1, P2, P3）とIssue番号の組み合わせで、次に作業すべき最も重要なタスクを自動的に見つけ出します。
次に、選ばれたIssueの詳細な内容（タイトルや説明）が、AIであるClaude Codeにプロンプトとして渡されます。Claude Codeは、この指示に基づいて必要なコードの生成や既存コードの修正といった実装作業を行います。
実装が完了すると、スクリプトは自動でGitのブランチを切って、AIが行った変更をステージングし、コミットします。さらに、オプションで指定すれば、GitHub上でPull Request（PR）の作成まで自動で実行してくれます。これにより、人間が手動で行っていた一連の開発サイクル（タスク選定、実装、コミット、PR作成）の一部がAIによって自動化されるわけです。
このシステムでは、AIが開発したプロセス全体を詳細に記録する機能も備わっています。Claude Codeの出力ログ、Gitの差分、セッションのメタデータなどが履歴として保存され、後からAIの作業内容を検証したり、学習データとして活用したりできるようになっています。
このスクリプトを利用するためには、事前にGitHub CLI（ghコマンド）、JSONデータ処理ツールのjq、そしてAIであるClaude Codeがインストールされている必要があります。また、AIが効果的に機能するように、GitHub Issueのテンプレートを整備したり、プロジェクトのドキュメントを適切に管理したりといった準備も推奨されています。
記事の冒頭には、この自動開発システムがまだ試験段階にあり、その利用は自己責任で行うべきであるという重要な注意事項が明記されています。
新人エンジニアの皆さんにとって、AIが開発現場でどのように活用され、私たちの仕事の進め方にどんな影響を与えるのかを考える良い機会になるでしょう。このような先進的な取り組みに興味があれば、ぜひ内容を深く理解した上で、試してみてはいかがでしょうか。
引用元: https://memotty-obsidian.pages.dev/202506151218-claude-code%E3%81%A8github-issue%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%9F%E5%85%A8%E8%87%AA%E5%8B%95%E9%96%8B%E7%99%BA%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/
AIエージェントがプログラムを書く｢バイブコーディング｣急拡大。関連スタートアップが急成長の一方、プログラマー削減の動きもいま、AIエージェントが自動でプログラムを書く新しい開発手法「バイブコーディング」が急速に広がっており、ソフトウェア開発の世界に大きな変化をもたらそうとしています。新人エンジニアの皆さんも、この最新のトレンドを理解しておくことは、これからのキャリアを考える上でとても大切です。
2025年は「AIエージェント元年」とも呼ばれるほど、自分で考えて行動するAIエージェントが次々と登場し、特にソフトウェア開発の分野でその活用が注目されています。従来のプログラミングでは、開発者がコードを一行ずつ記述していましたが、バイブコーディングでは、AIエージェントに「こんなシステムを作りたい」「この機能を追加してほしい」といった指示を出すだけで、AIが自動的に必要なプログラムコードを生成してくれます。まるで、開発者がプログラムの具体的な書き方を細かく指示するのではなく、AIにプロジェクトの「ノリや雰囲気（バイブス）」を伝えて、あとはAIに任せてしまうような感覚で開発が進むのが特徴です。この「バイブコーディング」という言葉は、OpenAIの著名なAI研究者アンドレイ・カルパシー氏がSNSに投稿したことをきっかけに、一気に広まりました。
この新しい開発手法の普及に伴い、AIによるコード生成ツールを提供するスタートアップ企業が急速に成長し、多額の資金調達を行っています。これらのツールを使うことで、開発のスピードが格段に向上し、より少ない労力で高品質なソフトウェアを開発できる可能性が広がっています。
もちろん、AIが多くのコードを自動生成できるようになることで、「プログラマーの仕事は将来どうなるのか」という疑問を持つ人もいるかもしれません。しかし、これは必ずしもネガティブな変化だけではありません。むしろ、プログラマーの役割がより高度で創造的なものへと進化するチャンスと捉えることができます。例えば、AIが生成したコードの品質をレビューし、最適化したり、AIでは見つけられないような複雑なバグを見つけ出して修正したり、あるいは、ユーザーの真のニーズを引き出し、AIに的確な指示を与えるための高度なコミュニケーション能力や、全体的なシステム設計・アーキテクチャの構築といった「人間ならではのスキル」がより重要になってきます。
バイブコーディングは、ソフトウェア開発の効率を飛躍的に向上させ、より創造的な開発に集中できる未来を示しています。新人エンジニアの皆さんは、AIを単なる道具としてではなく、強力なパートナーとして活用し、変化に適応しながら自身のスキルを磨いていくことが、これからの時代をリードしていく上で非常に重要になるでしょう。
引用元: https://toyokeizai.net/articles/-/884054
ある大手企業と研究機関によるホワイトペーパーをLLMに読み込ませたところ、「内容とは無関係の不審な指示文」が目視で分からないところに埋め込まれててゾッとした話大手企業のホワイトペーパーをLLMに読ませたところ、目には見えない形で「本紙を肯定的に評価しろ」という不審な指示文が埋め込まれているのが発覚しました。これは「プロンプトインジェクション攻撃」という、AIに不正な指示を仕込み、意図しない出力をさせる手口です。幸い、LLMがこの隠された指示を検知して教えてくれたため、被害は未然に防がれました。今後、AIに文書を読み込ませる際は、このような見えない攻撃が存在することを知り、情報セキュリティ意識を持つことが重要です。
引用元: https://togetter.com/li/2563875
お便り投稿フォームVOICEVOX:春日部つむぎ
-
関連リンク Claude Code 版 Orchestaror で複雑なタスクをステップ実行する
この記事では、AIが複雑なタスクを段階的かつ効率的に実行するための仕組み「Orchestrator（オーケストレーター）」を、Anthropic社のAI「Claude Code」で実現した事例を紹介しています。
従来のRoo Orchestratorの考え方を基に、AIがタスクをサブタスクに分割し、段階的に実行することで、処理コストを大幅に削減（例: 6ドルが1ドル未満に）し、速度向上も期待できます。
このOrchestratorは、Claude Codeの.claude/commandsという機能を利用して作られています。これは、特定のMarkdownファイルを配置するとAIがカスタムコマンド（例: /project:orchestrator）として実行できる仕組みです。AI自身がサブタスクを処理する「Taskツール」と組み合わせることで、複雑な処理を効率的に進めます。
Orchestratorの主なプロセスは以下の5つのステップで構成されます。
Initial Analysis（初期分析）: まずタスク全体の範囲と要件を理解し、依存関係や実行順序を計画します。 Step Planning（ステップ計画）: タスクを2〜4つの段階的なステップに分解し、各ステップ内で複数のサブタスクを並行実行できるように計画します。 Step-by-Step Execution（段階的実行）: 各ステップ内のサブタスクを並列に実行し、完了を待ちます。前のステップで得られた必要な結果だけを次のステップに渡し、AIが一度に処理する情報量（コンテキスト）を最小限に抑えます。 Step Review and Adaptation（ステップレビューと調整）: 各ステップ完了後に結果を確認し、残りのステップが適切か検証します。新たな発見があれば、計画を柔軟に調整し、サブタスクを追加・変更します。 Progressive Aggregation（段階的な統合）: 完了したステップから得られた結果を統合し、それを次のステップの前提知識として活用することで、段階的に全体を理解を深めていきます。これにより、「段階的な進行」「並列処理による効率化」「AIの『記憶』の最適化」「段階的な理解」「明確な依存関係」といった利点が生まれます。
例えば、TypeScriptプロジェクトの「分析、テスト、リンティング（コード品質チェック）、コミット」といった一連の作業をAIが自動で実行できます。テストやリンティングでエラーが見つかればAIが修正を試み、不要な修正ステップをスキップするなど、状況に応じて計画を柔軟に調整できます。
AIエージェントを効果的に活用するには、「最初にタスク全体を調査・計画」「サブタスクを並列実行」「各ステップ後に計画を見直し」が重要です。これにより、AIは複雑な開発タスクをより賢く、効率的にこなせるようになります。
引用元: https://zenn.dev/mizchi/articles/claude-code-orchestrator
Benchmarking Multi-Agent Architecturesこの記事では、複数のAIエージェントが連携して動作する「マルチエージェントシステム」の設計パターンと性能について、LangChainの公式ブログが実施したベンチマーク結果を解説しています。
なぜマルチエージェントが必要か？これまでの単一AIエージェントは、扱うツールや情報（コンテキスト）が増えると性能が低下するという課題がありました。これは、人間が一度に処理できる情報量に限界があるのと似ています。そこで、役割ごとにエージェントを分割し、互いに連携させる「マルチエージェントシステム」が注目されています。これにより、システムがモジュール化され、開発・評価・保守がしやすくなる上、異なるチームが開発したエージェントを組み合わせることも可能になります。
３つの代表的なアーキテクチャLangChainでは、代表的なマルチエージェントの連携方法として以下の3つを比較検証しました。
Single Agent: 全てのツールと情報にアクセスできる従来の単一エージェントです。性能の基準となります。 Swarm: 各エージェントがお互いの存在を認識し、必要に応じてタスクを他のエージェントに「ハンドオフ」（引き渡し）します。一度にアクティブになるのは1つのエージェントのみで、ユーザーへの応答は直接エージェントが行います。 Supervisor: 「スーパーバイザー」と呼ばれる中心のエージェントが、ユーザーからの入力を受け取り、適切なサブエージェントに作業を割り振ります。サブエージェントの応答は一度スーパーバイザーに戻され、スーパーバイザーが最終的にユーザーに返答します。この方式はサブエージェントへの仮定が少なく、最も汎用性が高いのが特徴です。ベンチマーク結果とSupervisorの改善テストは、関連性のない「おとり」（ディストラクタ）情報を含むタスクで、エージェントがどう情報を選別し処理するかを評価しました。結果として、Single Agentはディストラクタが増えると性能が急激に低下しましたが、SwarmとSupervisorは比較的安定した性能を示しました。特にSupervisorは、サブエージェントの応答をスーパーバイザーが「翻訳」してユーザーに伝える過程で、性能低下やトークン使用量の増加が見られました。これはまるで伝言ゲームのようで、情報がうまく伝わらないことが原因でした。
しかし、LangChainはSupervisorアーキテクチャにいくつかの重要な改善を施しました。
ハンドオフメッセージの削除: サブエージェントのコンテキストから不要な情報を取り除き、処理能力を向上させました。 メッセージの直接転送: スーパーバイザーがサブエージェントの応答を直接ユーザーに転送する機能を追加し、不正確な言い換えによるエラーを減らしました。これらの改善により、Supervisorアーキテクチャの性能は約50%向上しました。まとめマルチエージェントシステムは、今後のAIエージェント開発において非常に重要になると考えられています。特にSupervisorアーキテクチャは汎用性が高く、様々なシナリオで利用できる可能性があります。今回の研究で得られた情報伝達やコンテキスト管理の改善点は、langgraph-supervisorというLangChainのパッケージに組み込まれており、エンジニアはこれを利用することで、高性能なマルチエージェントシステムを容易に構築できるようになります。
引用元: https://blog.langchain.dev/benchmarking-multi-agent-architectures/
OpenAI Agents の TypeScript SDKOpenAI Agents SDKは、AIエージェントをTypeScriptで簡単に構築・管理するための軽量なパッケージです。以前の実験的なプロジェクト「Swarm」を本番環境向けに改良したもので、AIエージェント開発を始める新人エンジニアにとって非常に役立つツールです。
このSDKの主な特徴と機能は以下の通りです。
エージェントの定義と実行: 基本的なAIエージェント（Agentクラス）をTypeScriptで簡単に定義できます。エージェントには「指示」（instructions）や「使用するモデル」（model）を設定し、特定のタスクを完了するまで自動で動作させられます。 run関数を使ってエージェントを実行し、結果を受け取れます。リアルタイムな対話のために、結果をストリーミングで受け取ったり、Zodスキーマを使ってAIの出力形式を厳密に定義したりすることも可能です。 対話履歴（history）を保持することで、チャットボットのように連続した会話も実現できます。 豊富なツール連携: エージェントが外部のデータや機能にアクセスするための「ツール」を柔軟に利用できます。 ホスト型ツール: OpenAIのサーバー上で動くWeb検索、コード実行、画像生成などの組み込みツールをすぐに使えます。例えば、最新情報を取得するためにエージェントにWeb検索をさせられます。 関数ツール: TypeScriptの関数をツールとして定義し、Zodスキーマで入力・出力の型を明確にすることで、型安全に独自の機能（例：計算ツール）をエージェントに提供できます。 エージェント自身をツールとして利用: 作成したエージェントを他のエージェントが呼び出せるツールとして登録し、専門性のあるエージェント同士で連携させることが可能です。 信頼性と制御の強化: ガードレール: エージェントへの入力や、エージェントが生成する出力を検証する機能です。これにより、不適切な内容をフィルタリングしたり、特定の形式（例：川柳）に沿っているかをチェックしたりして、エージェントの動作を安全に保てます。 Human-in-the-Loop (HITL): エージェントが実行する重要なアクション（例：支払い）の前に、人間の承認を挟むことができます。これにより、意図しない自動実行を防ぎ、より安全なシステムを構築できます。 開発・デバッグ支援: トレース: エージェントのワークフローを視覚的に確認できる機能があり、デバッグや動作の監視に役立ちます。OpenAI Agents SDKは、これらの機能を通じて、TypeScriptエンジニアがAIエージェントを開発・運用する際の生産性と信頼性を高めるための強力な基盤を提供します。
引用元: https://azukiazusa.dev/blog/openai-agents-sdk-typescript
お便り投稿フォームVOICEVOX:ずんだもん
-
関連リンク AI領域における組織の強みを活かすアーキテクチャ設計
AI Shift社が開発する企業向けAIエージェント構築プラットフォーム「AI Worker」について、開発チームとAIチームが協力し、組織の強みを最大限に活かすアーキテクチャ設計をどのように模索したかを紹介します。
AIエージェント開発における課題と変化かつてはAIチームの研究力がプロダクトの強みでしたが、2024年からのLLM（大規模言語モデル）の急速な進化により、AIチームの研究と市場の変化にずれが生じました。開発チームはLLMのAPI組み込みに注力するようになり、AIチームとの連携が一時的に薄れる課題がありました。しかし2025年、AIエージェントが注目され、LLMだけでなく、多様なツール連携や記憶管理など、より複雑な要素が必要になったことで、開発チームもAIの専門領域に、AIチームも開発ノウハウに踏み込む必要が出てきました。
組織の強みを活かすアーキテクチャ設計のポイント
責務の再定義とチーム統合:AIエージェント開発では、AIチームの役割がアプリケーション層まで広がるため、サービス単位で責務を分けるのではなく、開発チームとAIチームを統合し、同じ実行エンジンサービス内でそれぞれの専門性を活かすようにしました。これにより、DB選定やHTTPサーバ構築など、AIチームが開発領域にも関われるようになります。
開発言語の統一（TypeScript）:元々異なる言語（AIチーム：Python、開発チーム：TypeScript）を使っていたところを、AIエージェントの実行エンジンもTypeScriptに統一しました。これは、他サービスのアーキテクチャを参考にできる、チーム間の知識共有がしやすくなる、開発速度が向上するといったメリットがあるためです。
AIエージェントフレームワーク「Mastra」の採用と向き合い方:TypeScript製のAIエージェントフレームワーク「Mastra」を採用することで、開発の初期スピードを上げられました。Mastraは、エージェントやワークフロー、RAG（検索拡張生成）などの主要機能に加え、デバッグや運用機能も充実しています。一方で、AIエージェントの分野は変化が激しいため、特定のフレームワークに過度に依存せず、将来的に別のフレームワークに乗り換えられるように、重要な機能（例：データ永続化のための短期記憶）はMastraの機能を使わず、独自でPostgreSQLを導入するなど、疎結合な設計を意識しています。これは、柔軟な設計と将来への備えのためです。
疎結合な設計とFeature Flagの活用:異なるチームが同じコードを触るため、コードベースでの「依存性の逆転」と「疎結合な責務分離」を徹底しました。これは、Mastraのワークフローを「ユースケース層」、記憶管理を「インフラ層」と捉え、それぞれが独立するように設計することで、テストのしやすさや、変更時の影響範囲を小さく保つための工夫です。また、LLMの不確実性に対応するため、実装と検証を高速で回せる「Feature Flag」の仕組みを導入しました。これにより、新しい機能を本番環境に影響なく検証し、迅速に改善サイクルを回すことが可能になりました。例えば、AIエージェントの振る舞いを刷新するプロジェクトを、Feature Flagを活用することで約1ヶ月で本番リリースまで漕ぎつけ、長期的なR&Dの高速化に貢献しました。
まとめAIエージェント開発では、開発チームとAIチームがお互いの領域に踏み込み、協力し合うことが重要です。そのためには、疎結合で柔軟なアーキテクチャ設計と、Feature Flagを活用した高速な検証サイクル基盤の構築が不可欠であり、これらが市場の変化に対応し、プロダクトを成長させる鍵となります。
引用元: https://zenn.dev/aishift/articles/c897d0e095c3d8
Agent Development Kit によるエージェント開発入門タイトル: Agent Development Kit によるエージェント開発入門
要約:この資料は、大規模言語モデル（LLM）を基盤とした「AIエージェント」を開発するための入門ガイドです。新人エンジニアの皆さんが、AIエージェントの基本的な仕組みや開発の流れを理解するのに役立つ内容となっています。
まず、LLMが単なる質問応答にとどまらず、より複雑なタスクをこなす「エージェント」として機能するために必要な技術が説明されます。重要なのは、「情報検索（RAG: Retrieval-Augmented Generation）」と「Function Calling」です。RAGは、LLMが持つ既存の知識だけでなく、外部のデータベースやウェブ検索から最新情報を取得し、それを踏まえて回答を生成する仕組みです。これにより、LLMの知識をリアルタイムに拡張し、より正確な情報を提供できるようになります。Function Callingは、LLMがユーザーの意図を理解し、その意図に基づいて外部のツール（APIなど）を呼び出し、特定の処理を実行する能力です。例えば、「東京と京都の気温差を教えて」という質問に対して、LLMが自ら気象情報APIを呼び出し、必要なデータを取得・計算して回答を生成するといった、具体的なタスクの自動実行が可能になります。
これらのエージェントを効率的に開発するためにGoogleが提供するのが「Agent Development Kit (ADK)」です。ADKは、エージェントの構築に必要な機能を抽象化しており、開発者が複雑な実装ロジックを直接書く手間を減らします。ADKでは、LLMの振る舞いを定義するLlmAgentオブジェクトや、エージェントの実行・管理を行うRunnerオブジェクトといった主要なコンポーネントが提供され、これにより簡単にエージェントアプリケーションを構築できます。
さらに、ADKを活用することで、より複雑なエージェント構成も可能です。例えば、「サブエージェント」という概念では、特定の専門知識や機能を持つ複数のエージェントを用意し、ユーザーの質問内容に応じて最適なエージェントに処理を振り分けます。これにより、それぞれのエージェントが連携しながら、より高度で専門的な対話を実現できます。また、「Agent as a Tool」というパターンでは、別エージェントをあたかも一つのツールであるかのように扱い、他のエージェントから呼び出して利用することも可能です。
開発したエージェントは「Agent Engine」を使ってデプロイ（公開）できます。また、他のAIエージェントとの連携を容易にする「A2A (Agent to Agent) サーバー」と組み合わせたり、「Agentspace」のようなプラットフォームに登録して利用したりすることで、開発したエージェントの活用範囲を広げることができます。
この資料を通じて、AIエージェントがどのように外部の情報やツールと連携し、賢く振る舞うのか、そしてそれらを効率的に開発するための基本的なフレームワークや構成パターンについて、基礎を学ぶことができます。
引用元: https://speakerdeck.com/enakai00/agent-development-kit-niyoruezientokai-fa-ru-men
AIエージェント「Cursor」で変わる開発マネジメントの実践論この記事は、AIを搭載したコードエディタ「Cursor」を使い、開発組織のマネジメントをどのように効率化していくかについて書かれています。AIの活用というと、コードを書く手助け（AI-assisted coding）がまず思い浮かぶかもしれませんが、この記事では、それだけでなく「開発プロセス全体」にAIを導入することの重要性を強調しています。
筆者は、開発プロジェクトにかかる全時間（リードタイム）を分析すると、実際にコードを書く「開発フェーズ」以外にも、企画、会議、ドキュメント作成、管理業務といった部分に多くの時間が費やされていることを指摘しています。これらの「開発フェーズ以外の課題」にAIを導入することで、組織全体の生産性を大幅に向上させることができる、と述べています。
Cursorを活用した具体的なマネジメント術として、以下の点が紹介されています。
マネジメントの知見蓄積とワークフロー化:日々の業務で得られる情報や知識を体系的に整理し、Cursorの自動化機能（Rules）を使って、毎月の工数計算やライセンス費用計算といった定型業務を自動化できます。ただし、チームの経験に基づく判断や、メンバー間の深い対話が必要な1on1ミーティングなどは、AIに任せず人間が行うべきだと注意喚起しています。
エンジニアが開発に集中できる環境作り:マネージャーがエンジニアに質問する手間を減らし、エンジニアが本来の開発業務に集中できるよう、AIを活用します。
類推見積もり: 「この機能を作るのにどれくらい時間がかかる？」という概算の見積もりを、AIに過去の類似コードを分析させて算出できます。これにより、企画段階でエンジニアに聞かずに大まかな計画を立てることが可能です。 コードベースからの仕様自動抽出: AIにコードを解析させることで、APIの仕様やデータベースの構造、ビジネスロジックなどを自動で文書化できます。これにより、システムの詳細を知りたいときに、エンジニアに直接聞かずに最新情報を素早く得られます。例えば、シーケンス図の作成もCursorに指示して行えます。 投資工数の分析: エンジニアが「新規開発」「既存機能の改善」「保守」「運用」「管理業務」のどの作業にどれくらいの時間を使っているかをAIで分析し、開発業務に集中できているかを確認できます。これらの活用により、AIはコード作成だけでなく、書類選考の効率化、要件定義のたたき台作成、会議の改善、テストの自動化など、開発組織の様々な業務に貢献し、全体の生産性を向上させると締めくくられています。
新人エンジニアの皆さんにとって、AIがコードを書くだけでなく、開発プロジェクトの運営やチームマネジメントにどのように貢献できるかを知ることは、今後のキャリアを考える上で貴重な視点となるでしょう。
引用元: https://developersblog.dmm.com/entry/2025/06/09/110000
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク メルカリにおけるデータアナリティクス AI エージェント「Socrates」と ADK 活用事例
メルカリは、膨大な社内データを持ちながらも、SQLなどの専門知識がないとデータ活用が難しいという課題に直面していました。データ分析の依頼が特定のアナリストに集中し、迅速な意思決定が阻害されることもあったため、「誰もがもっと手軽にデータと対話できる」仕組みが求められていました。
この課題を解決するために、メルカリはデータアナリティクスAIエージェント「Socrates（ソクラテス）」を開発しました。Socratesは、ユーザーが普段使う言葉（自然言語）で質問するだけで、まるで優秀なデータアナリストと会話するようにデータ分析を進められるシステムです。従来の「Text2SQL」（テキストからSQLを自動生成する技術）が単純な質問にしか対応できないのに対し、Socratesは「推論（思考）」と「行動（ツール利用）」を組み合わせることで、より複雑なデータ分析や仮説検証、レポート作成支援までを自動化します。これにより、データ分析の「民主化」とビジネスにおける「意思決定の迅速化」を目指しています。
Socratesが自社開発された背景には、高性能なLLM（大規模言語モデル）やAIエージェント構築ライブラリの登場、そしてメルカリに高品質なデータ資産（Basic Tables）が整備されていたというタイミングが重なりました。メルカリは、AIエージェントの核となる技術が汎用化する可能性を見据え、データの構造化や社内ナレッジの整備といった、他社が模倣しにくい「周辺資産」への早期投資と、それらを活用できる「AI Agent Ready」な組織への変革を重視しています。
Socratesの開発には、Googleが提供するAIエージェント開発フレームワーク「ADK (Agent Development Kit)」が活用されています。ADKは、Google Cloudのサービス（BigQueryやVertex AIなど）とスムーズに連携でき、複数の専門エージェントが協力して動く「マルチエージェントアーキテクチャ」の設計を支援します。Socratesでは、このADKを基盤に、BigQueryでのSQL実行、Pythonによるデータ処理、社内ドキュメント検索など、多様なツールと連携することでデータ分析のワークフローを自動化しています。
AIエージェントの運用は、機械学習システムの運用（MLOps）と同様に複雑です。メルカリでは、Socratesの応答品質やタスク達成度を評価するため、オフラインテスト、ユーザーからのフィードバック、さらには「Agent as a Judge」（別のAIエージェントがSocratesの応答を評価する）といった多角的なアプローチで継続的な改善を行っています。また、応答速度（レイテンシ）の改善、コスト最適化、セキュリティ対策（プロンプトインジェクション防止、情報漏洩対策など）にも力を入れています。ADKはGoogleエコシステムとの親和性が高く開発を加速させましたが、一部の課題も認識しており、今後の進化に期待を寄せています。
メルカリの事例は、AIエージェントが企業内のデータ活用を大きく変革する可能性を示しています。AIエージェントは、単に開発するだけでなく、データやドキュメントといった「周辺資産」を整備し、組織文化や業務プロセスを「育て続ける」ことが成功の鍵となります。
引用元: https://speakerdeck.com/na0/merukariniokerudetaanariteikusu-ai-eziento-socrates-to-adk-huo-yong-shi-li
「世界初の汎用AIエージェント」を豪語、中国発「Manus」がヤバすぎる理由中国のAIスタートアップ「Butterfly Effect」が開発したAIエージェント「Manus」が、AIコミュニティで大きな注目を集めています。同社はこれを「世界初の汎用AIエージェント」と称し、OpenAIの「Deep Research」を超える性能を持つと豪語しています。
「Manus」は、AnthropicのClaude 3.5 SonnetやAlibabaのQwenモデルをベースにした「マルチエージェントシステム」を採用しています。これは、複数のAIが連携して働くことで、より複雑なタスクに対応できる仕組みです。初期の専門家による評価は非常に高く、例えば、犯罪率や起業家密度といった複数の要素を考慮してサンフランシスコの賃貸物件を探したり、リアルタイムのデータを使って自己紹介サイトを作成・公開したりといった、複雑で具体的なタスクを高い精度で実行できたと報告されています。元Google社員のYouTuberも、「最も自律的なAIエージェントに近い」と評価し、様々なタスクでその能力を検証しています。
しかし、2025年4月の一般公開後、ユーザーからの評価は賛否両論に分かれています。新規登録者には無料クレジットが提供されるものの、簡単なタスクでも大量のクレジットを消費するため、無料で試せる回数はごく限られます。月額料金も高額で、これに対しては「法外に高い」という声も上がっています。
実際にユーザーが試したところ、データ入力の自動化や物件探しなど、タスクによっては期待通りの成果が得られなかったり、全く意図しない情報が生成されたりする失敗例も報告されています。一方で、非常に時間のかかる作業を短時間で完了できたといった成功体験も聞かれます。
専門家からは、デモでAIエージェントの可能性が示された一方で、自律的に行動するAIエージェントが、株式売買などの重要なタスクを自動で行うことにはまだ慎重な姿勢を示す意見もあります。
「Manus」は、汎用的なAIエージェントの可能性を示すものですが、実用化にはコスト面や精度、そしてAIが自律的に行動することのリスクなど、まだ多くの課題があることが伺えます。
引用元: https://www.sbbit.jp/article/cont1/165679
LangGraph Release Week RecapAIエージェント開発に挑戦中の皆さん、こんにちは！AIエージェントを構築するフレームワークLangGraphが、Python版とJavaScript版で大規模な新機能アップデートを行いました。今回の機能追加は、AIエージェントの開発効率を大幅に高め、より柔軟な制御を可能にするものです。新人エンジニアの皆さんが、AIエージェント開発をスムーズに進める上で役立つポイントをご紹介します。
AIエージェント開発を加速する共通の新機能 ノードキャッシュ（Node Caching）で開発サイクルを高速化 LangGraphの各処理ステップ（ノード）の計算結果をキャッシュ（一時保存）できるようになりました。AIエージェント開発では試行錯誤が多く、同じ計算を繰り返す場面が頻繁にあります。ノードキャッシュにより、以前の計算結果を再利用できるため、実行速度が向上し、開発効率が大きく改善します。 遅延ノード（Deferred Nodes）で複雑なワークフローをシンプルに 特定のノードの実行を、関連するすべての先行処理が完了するまで待機させることが可能になりました。これにより、複数のAIエージェントが協力して情報を集め、それらが揃ってから最終決定を下すといった、複雑な「map-reduce」や「コンセンサス」型のワークフローを、より効率的に構築できます。 モデル前/後フック（Pre/Post Model Hook）でエージェントの挙動を詳細に制御 AIモデルが応答を生成する前後に、独自の処理を挿入できるようになりました。例えば、AIモデルに渡す会話履歴を要約してコストや応答速度を最適化したり（前フック）、AIの生成内容をチェックして不適切な応答を防ぐ「ガードレール」を設けたり（後フック）することが可能になります。これにより、より安全で効率的なAIエージェントを開発できます。 組み込みプロバイダツール（Builtin Provider Tools）で外部サービス連携を強化 Web検索ツールやリモート操作ツールなど、外部の便利なツールをLangGraphのAIエージェントに簡単に組み込めるようになりました。これにより、AIエージェントが最新の情報を取得したり、外部システムと連携して多様なタスクを実行したりと、AIエージェントの能力を飛躍的に拡張できます。 JavaScript開発者向け！さらに便利な機能 再開可能なストリーム（Resumable Streams）でアプリケーションの堅牢性を向上 JavaScript版では、リアルタイムな情報ストリームがネットワーク問題などで中断されても、自動的に中断箇所から再開できるようになりました。ユーザー体験が向上し、データが途中で失われる心配が減ります。 開発者体験の向上（DevX Improvements）でスムーズな開発を実現 コードの「型安全」が強化されたり、複雑なワークフローをより少ないコードで記述できるようになったりしました。これにより、特に新人エンジニアの皆さんがコードを書く際のミスが減り、開発がよりスムーズに進められるよう改善されています。今回のアップデートにより、LangGraphを使ったAIエージェント開発は、より高速に、より堅牢に、そしてより柔軟に行えるようになりました。これらの新機能を活用し、ぜひ皆さんの手で新しいAIエージェント開発に挑戦してみてください！
引用元: https://blog.langchain.dev/langgraph-release-week-recap/
Gatebox、竹中工務店とAI活用で協業、AIキャラクターがオフィスビルの設備を自在に操作する実証実験を実施Gateboxと竹中工務店が協業し、AIキャラクターがオフィスビルの照明や空調などを音声で操作するシステムを開発しました。これは、従来の個人宅向けではなく、オフィスやホテルなどの大規模な建物で多様な設備を遠隔操作できるのが特徴です。自然な会話で設備を制御できるため、オフィスワーカーや宿泊者など、様々な利用者の利便性や快適性を向上させることを目指しています。AIが身近な場所で活躍する未来が楽しみですね。
引用元: https://prtimes.jp/main/html/rd/p/000000120.000026497.html
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク OpenSearch 3.0 でMCPによるAgentとの連携を行ってみる
この記事では、OpenSearch 3.0の最新機能、特に「MCP（Model Context Protocol）」を活用したAIエージェントとの連携方法について、新人エンジニアの方にも分かりやすく解説されています。
OpenSearchは、大量のデータの中から必要な情報を素早く探し出すための、強力な検索エンジン（データベースの一種）です。今回リリースされたバージョン3.0では、AI技術との連携が大きく進化しました。中でも注目すべきは、AIエージェントが外部のデータやツールとスムーズにやり取りするための共通ルールであるMCPに、OpenSearchが標準で対応した点です。これにより、OpenSearchは単なる検索システムから、より賢く、幅広い情報に対応できるプラットフォームへと進化しています。
OpenSearch 3.0の主な更新点は以下の通りです。
MCP（Model Context Protocol）への標準対応: AIエージェントとの連携を容易にします。 検索性能の大幅向上: Lucene 10やJDK 21へのアップグレードにより、特にAI関連で重要な「ベクター検索」の速度が改善しました。ベクター検索とは、言葉の意味の近さを基に情報を探す高度な検索方法です。 データ分析機能の強化: PPL（Piped Processing Language）というデータ分析言語が強化され、ログの相関分析などがしやすくなりました。 ダッシュボード機能の強化: 「Workspaces」という機能が追加され、ユーザーごとにカスタマイズされたデータ表示画面を提供できるようになりました。記事では、このMCP連携の具体的な2つのパターンが紹介されています。
1. OpenSearchから外部のMCPサーバーを利用する構成このパターンでは、OpenSearchが「質問役」となり、外部にあるAIエージェント（MCPサーバー）に情報を問い合わせます。例えば、OpenSearchに投げられた質問に対して、AIエージェントがAWSの公式ドキュメントを参照して回答するといった使い方ができます。これにより、OpenSearchの内部データだけでなく、外部の豊富な情報源も合わせて活用できるようになります。
2. 外部のMCPサーバーからOpenSearchを呼び出す構成こちらは反対に、外部のAIエージェントが「質問役」となり、OpenSearch内のデータを参照するパターンです。記事では、Claude DesktopのようなAIアシスタントがOpenSearchに蓄積された商品データに対して質問を投げかけ、適切な回答を得る例が示されています。これにより、既存のOpenSearchに保存されている大事なデータを、AIエージェントから簡単に活用できるようになります。
このように、OpenSearch 3.0のMCP対応は、AIエージェントがOpenSearchのデータや機能をより柔軟に利用できる道を開きます。システム全体として、AIがより賢く、ユーザーの要求に応えられるようになるため、今後のAI活用の幅がさらに広がるでしょう。
引用元: https://acro-engineer.hatenablog.com/entry/2025/06/09/120000
The no-nonsense approach to AI agent development - Vercelこの記事は、AIエージェントの開発を、新人エンジニアでも理解しやすいよう、実践的かつ分かりやすい3ステップで解説しています。
AIエージェントとは、これまで人手で行っていた、複数のステップと判断が必要な複雑なタスクを自動化するソフトウェアシステムです。従来の自動化では難しい、文脈理解や状況判断、適応力が求められる作業に向いています。最も効果的なAIエージェントは、特定の領域に特化し、目的を狭く絞り込むことで実現できます。
AIエージェント開発は、次の3つのステップで進められます。
ステップ1：手動でプロトタイプを作るまず、コードを書く前に、人間がタスクを行うように手作業でエージェントの動きをシミュレーションします。具体的な入力データを使って、大規模言語モデル（LLM）にプロンプトを手動で与え、タスクを最後まで進めてみます。この過程で、繰り返し行われる機械的な作業を見つけ出し、どこを自動化できるかを見極めます。もし、この段階でLLMがうまくタスクを完了できないようであれば、そのタスクはAIエージェント向きではないかもしれません。
ステップ2：タスクのループを自動化する手動シミュレーションでタスクが実行可能だと分かったら、いよいよコードを書き始めます。ここでは、エージェントの基本的な骨格を構築します。入力データの収集（APIやスクレイパーなど）を自動化し、タスクのプロセスをループや状態機械としてコードに落とし込みます。特に重要なのは、LLMの役割を明確にすることです。LLMは推論や判断が必要な部分にのみ使用し、データ解析や計算、ソートといった決定的（常に同じ結果が得られる）な処理は、通常のプログラミングコード（if文やループなど）で実装します。AIエージェント開発も、通常のソフトウェア開発の原則に沿って進めることが強調されています。
ステップ3：信頼性を最適化するエージェントがエンドツーエンドで動作するようになったら、次は品質と信頼性の向上に注力します。プロンプトを洗練させ、ツールの呼び出しをより正確にし、不要なリトライを減らします。LLMが提供する結果の精度が低い場合は、別のLLMを使って結果を批判的に評価し、改善を促すことも有効です。手動でのテストに加え、さまざまな種類の入力データやエッジケースに対するパフォーマンスを評価するために、構造化された評価（テストスイートのようなもの）を導入し、品質の維持と向上が図られます。
まとめると、AIエージェント開発は、通常のソフトウェア開発の基本原則（明確なロジック、良い構造、密なフィードバックループ）に基づいて行われます。実装前に手動でテストし、LLMを本当に必要な判断部分にのみ活用し、そして徹底的に品質をテストすることで、信頼性の高いエージェントが構築できるのです。
引用元: https://vercel.com/blog/the-no-nonsense-approach-to-ai-agent-development
Apple supercharges its tools and technologies for developers to foster creativity, innovation, and designAppleは先日、開発者向けのツールと技術を大幅に強化すると発表しました。これは、世界中の開発者がより創造的で革新的なアプリを効率的に作れるようにするためのものです。特に、AIやLLM（大規模言語モデル）の活用が注目されています。
主な強化点は以下の通りです。
Apple Intelligenceの活用: 開発者は、Appleデバイス上で動作するAIモデル「Apple Intelligence」をアプリに組み込めるようになります。これはオフラインでも使え、プライバシー保護を重視しています。 Swift言語でわずか数行のコードを書くだけで、このAIモデルの生成能力（テキスト生成など）をアプリに簡単に組み込めます。 Xcode 26の進化: 開発ツール「Xcode 26」に、ChatGPTなどのLLMを直接統合できるようになります。これにより、コードの自動生成、テストコードの作成、ドキュメント生成、エラー修正などがAIの助けを借りて行えるようになり、開発効率が大きく向上します。 「Liquid Glass」という新しいデザインが導入され、アプリのUI（ユーザーインターフェース）がより美しく、統一感のある体験を提供できるようになります。 新しい「Icon Composer」アプリを使えば、開発者が視覚的に魅力的なアプリアイコンを簡単に作成できます。 「Coding Tools」は、開発者がコードを書く際に適切なアクションを提案し、作業の流れをスムーズにします。 App Intentsの強化: アプリの機能とSiriやSpotlightなどのシステム機能をより深く連携させる「App Intents」が進化。特に「ビジュアルインテリジェンス」に対応し、画像検索結果から直接アプリにアクセスできるようになります。 プログラミング言語Swiftの進化: 「Swift 6.2」がリリースされ、パフォーマンスの向上、並行処理（複数の処理を同時に実行する）の記述の簡素化、そしてWebAssemblyへの対応が強化されました。これにより、より高速で安定したアプリ開発が期待できます。 コンテナ技術への対応: 「Containerization framework」が提供され、Mac上で直接Linuxのコンテナイメージを作成・実行できるようになります。これは開発環境の構築や管理を効率化します。 ゲーム開発ツールの強化: 「Game Porting Toolkit 3」で、WindowsからMacへのゲーム移植を効率化するためのツールが改善。 「Metal 4」では、Appleシリコンに最適化されたグラフィック技術が進化し、リアルタイムレイトレーシングなど、より高品質なゲーム表現が可能になります。 「Apple Games」アプリや「Game Overlay」といった新機能で、プレイヤー間の交流やゲーム体験をさらに豊かにする仕組みが提供されます。 子どものオンライン保護とApp Storeの改善: 「Declared Age Range API」により、開発者は子どもの年齢に応じた適切なコンテンツを提供できるようになり、保護者による設定でプライバシーも守られます。 App Storeのアプリ詳細ページに「Accessibility Nutrition Labels」が追加され、アプリがどのようなアクセシビリティ機能をサポートしているか利用者が事前に確認できるようになります。これらの強化により、Appleは開発者がより高度な機能と魅力的なデザインを持つアプリを、これまで以上に効率的に開発できる環境を提供し、ユーザー体験の向上を目指しています。
引用元: https://www.apple.com/newsroom/2025/06/apple-supercharges-its-tools-and-technologies-for-developers/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク AIの著作権問題に終止符か？ 8TBの巨大オープンデータセット「Common Pile」登場、Llama 2に匹敵するLLMもリリース XenoSpectrum
近年、生成AIは膨大なデータを学習して進化しましたが、その中には著作権保護コンテンツも多く含まれ、無断利用による著作権問題が深刻化しています。これによりAI開発企業は学習データの詳細を公開せず、研究の透明性が失われる「透明性の冬」という状況に陥っていました。
このような状況を打破するため、EleutherAIを中心とする共同研究チームが、画期的なテキストデータセット「Common Pile v0.1」を公開しました。これは8テラバイト（TB）もの膨大なデータ量を持つ点が特徴です。最大のポイントは、パブリックドメイン（著作権が消滅したものなど、誰もが自由に使える状態のコンテンツ）と、オープンライセンスのコンテンツ（使用、研究、変更、再配布が自由に許諾されているもの）のみで構築されている点です。特に「オープンの定義2.1版」という厳格な基準を採用し、誰もが自由に利用できるライセンスのコンテンツだけを選び、商用利用や改変が制限されるライセンスは排除されています。
Common Pileは、データ量だけでなく内容も非常に多様です。オープンソースのソースコード、政府・法律関連文書、学術論文など、30種類もの信頼できるソースから収集されています。また、インターネットに存在する誤ったライセンス表記（ライセンスロンダリング）や、個人情報、有害なコンテンツ、重複するデータなどを徹底的に取り除き、高品質を維持するための厳しい管理が行われています。
さらに驚くべきは、この「クリーンな」Common Pileで学習させた新しい言語モデル「Comma v0.1」が、Meta社の「Llama 2」など、ライセンスの透明性が低いデータで学習された既存の高性能モデルに匹敵する、あるいは一部で凌駕する能力を示したことです。これは「著作権を遵守すると高性能なAIは作れない」という従来の常識を覆す画期的な成果と言えます。
Commaモデルの高性能は、Common Pileに含まれる多様なデータソースの「混ぜ方（データミキシング）」を工夫した点にあります。品質の高いデータを優先的に学習させることで、限られた計算資源で効率的に知識を習得できました。
この「Common Pile」は、過去のデータセットにおける著作権問題の反省を活かし、法的・倫理的な正当性を最優先に据えた「The Pileの正統進化形」と位置づけられます。Common Pileの登場は、AI開発における著作権リスクを低減し、透明で倫理的なAI研究を加速させるための大きな一歩となるでしょう。これにより、開発者は安心してAIを開発でき、社会全体として説明可能で信頼できるAIの実現に貢献すると期待されています。
引用元: https://xenospectrum.com/8tb-massive-open-dataset-common-pile-now-available/
うさぎでもわかる🐰ヤバすぎclaude-bridgeでClaude CodeにGPT、Gemini、ローカルLLMを接続！無料でエージェント機能使い放題の革命的ツールこの記事では、AI開発ツール「Claude Code」をさらに便利にするオープンソースツール「claude-bridge」を紹介します。これまでClaude CodeはAnthropic社のAIモデルに限定されていましたが、「GPT-4oのような新しいモデルも試したいけど、そのためだけに別のツールを覚えるのは大変…」と感じていたエンジニアの皆さんに朗報です。claude-bridgeを使えば、Claude CodeからOpenAIのGPTシリーズ、GoogleのGemini、さらにはご自身のPCで動かせるローカルLLMまで、様々なAIモデルを利用できるようになります。
claude-bridgeは、Claude Codeが出すAIへのリクエストを「翻訳」し、指定された他のAIプロバイダーが理解できる形式に変換して転送する「プロキシ」として機能します。これにより、Claude Codeは普段通りに動作しますが、裏では自由に選んだAIモデルと連携できる「魔法」を実現しています。
このツールの最大の魅力は、特に「Ollama」というツールと組み合わせることで、自宅のPCに高性能なGPU（画像処理装置）があれば、AIエージェント機能を完全に無料で、そして無制限に使い放題にできる点です。これにより、高額なAPI利用料を気にすることなく、またプライベートなコードや機密情報が外部に送られる心配もなく、安全にAIを活用できるようになります。これは、コスト削減やプライバシー保護を重視する企業や個人の開発者にとって、非常に大きなメリットとなります。
インストールは「npm install -g @mariozechner/claude-bridge」と簡単で、使い方も「claude-bridge openai gpt-4o」のようにプロバイダーとモデルを指定するだけと非常にシンプルです。複数のAIモデルを比較しながらコード生成を行うなど、開発効率の劇的な向上が期待できます。
ただし、いくつかの制限事項もあります。例えば、Claude Codeの表示するAIのトークン使用量や費用は正確でなかったり、画像のアップロード機能が動作しなかったりします。また、OpenAIの特定のモデルではAIの「思考過程」が詳細に表示されない場合もあります。これらの制限を理解し、「あくまでハック的なツール」であることを念頭に置き、重要なプロジェクトで使う前には十分にテストを行うことが推奨されています。
claude-bridgeは、AIモデルの選択肢を広げ、コストを削減し、プライバシーを守りながら、AIエージェント機能を活用した開発を進めるための革新的なツールです。AI開発に興味のある新人エンジニアの皆さんは、ぜひ一度試して、その便利さを体験してみてください。
引用元: https://note.com/taku_sid/n/n189f2696a30e
The Illusion of Thinking: Understanding the Strengths and Limitations of Reasoning Models via the Lens of Problem Complexity最近のAIモデル（LLM）には、Large Reasoning Models（LRM）と呼ばれる、答えを出す前に詳細な「思考プロセス」を生成するものが登場しました。これらは推論能力のベンチマークで高い性能を示す一方で、その基本的な能力や、問題の規模が大きくなった時の特性、そして限界についてはまだ十分に理解されていませんでした。
これまでの評価は、主に数学やプログラミングの問題で、最終的な答えの正確さに注目していました。しかし、この評価方法には、学習データが汚染されている（テスト問題がすでにモデルの学習に使われている）可能性があり、モデルがどういう思考プロセスで答えを出したのか、その質や構造が分かりにくいという課題がありました。
そこでこの研究では、制御可能なパズル環境を使って、これらの課題を体系的に調べました。この環境では、問題の論理構造は変えずに、その「複雑さ」だけを細かく調整できます。これにより、最終的な答えだけでなく、LRMの内部でどのように「思考」が進んでいるのか（推論の軌跡）を詳細に分析することが可能になりました。
様々なパズルで広範な実験を行った結果、最新のLRMは、ある一定の複雑さを超えると、その回答精度が完全に崩壊してしまうことが分かりました。さらに、非常に興味深いことに、問題の複雑さが増すにつれて、LRMの「推論の努力」（思考に費やすリソース）は最初は増えるものの、ある時点を境に、たとえ十分な思考のためのリソース（トークン予算）があっても、かえってその努力が減少してしまうという、直感に反する限界があることが判明しました。
また、LRMと、思考プロセスを生成しない通常のLLMを同じ計算資源で比較すると、3つの異なる性能領域が見られました。1つ目は、簡単な問題では、意外にも通常のLLMの方がLRMよりも良い結果を出すことがあります。2つ目は、中程度の複雑さの問題では、LRMが追加の思考を行うことで有利になることが示されました。そして3つ目は、非常に難しい問題では、どちらのモデルも完全に問題を解けなくなる、という結果でした。
研究では、LRMが正確な計算に限界があること、明確な手順（アルゴリズム）を使えないこと、そしてパズルによって推論の仕方が一貫しないことも明らかになりました。これらの分析は、LRMの強みと限界を浮き彫りにし、最終的に彼らの本当の推論能力について重要な疑問が提起されています。
引用元: https://machinelearning.apple.com/research/illusion-of-thinking
特急に乗ってきた上品な感じのお婆さんが後ろの外国人に席を倒して良いか聞こうとして、翻訳アプリの発音機能を使ったら、響き渡った翻訳がこれで口角が上がりまくってしまった… たぶん駄目だよ特急列車内で、お婆さんが席をリクライニングするためAI翻訳アプリを利用したところ、「あなたを倒していいですか？」と誤訳され、周囲の笑いを誘うハプニングがありました。これは日本語の「倒す」が「リクライニング」と「打ち負かす」で多義的であることが原因です。AI翻訳の奥深さや、人間らしいユーモアに触れる面白い事例として、AIが身近な存在となった現代の微笑ましい一面を示しています。正しい英語表現についても解説されています。
引用元: https://togetter.com/li/2561307
お便り投稿フォームVOICEVOX:春日部つむぎ
-
関連リンク Open Source AI Agent: Build Full Stack Apps
この記事は、「app.build」という、オープンソースのプロジェクトを紹介しています。これは、AI技術を活用した「AI Agent」という仕組みを使って、Webアプリケーション開発の初めの一歩を助けてくれるツールです。具体的には、データベースからユーザーインターフェース（画面）まで一通り揃った「フルスタック」と呼ばれるアプリケーションの基本的なコードを、コマンド一つで自動的に生成してくれます。
使い方はとても簡単で、ターミナルでnpx @app.build/cliというコマンドを実行するだけです。生成されるアプリは、主にNeonというクラウド上で動くデータベースサービスなどを利用することを想定していますが、設定を変えたり、独自のテンプレートを使ったりすることも可能です。
app.buildの大きな特徴は、コードが全て公開されている「オープンソース」であることです。これにより、開発の仕組みを透明に見ることができ、誰もが自由に利用したり、改善に貢献したりできます。また、「ローカルファースト」が重視されており、皆さんの手元のPCですぐに動かして試せるように作られています。これは、これからWebアプリ開発を始めたい新人エンジニアの方にとっても、手軽にプロジェクトのひな形を作れる便利な出発点となるでしょう。
このプロジェクトは開発者向けに作られており、特にNeonのようなプラットフォーム上で動くコードをAIに自動生成させるツールを作る際の「参照実装」、つまりお手本となることを目指しているそうです。
プロジェクトのコードは、全てGitHubリポジトリで公開されています。興味があれば、どのようなコードでこのAI Agentが作られているのかを覗いてみることもできます。
このように、AIがソフトウェア開発の一部を自動化し、より効率的にアプリ開発を進められるようにする動きが進んでいます。app.buildは、AI Agentが実際にどのようにアプリケーションコードを生成できるかを示す具体的な例であり、今後の開発スタイルを考える上で参考になるプロジェクトと言えるでしょう。
引用元: https://www.app.build/
AI Agentで動くSNS人格に、ベクトル検索MCPで外部知識を持たせる前回の記事で作成した、SNS上で活動するAI Agent（架空の友達、今回はプリキュアオタクギャル）には、「最新情報や専門知識が足りない」という課題がありました。LLM（大規模言語モデル）は学習時点より新しい情報を持っていないため、例えば最新のプリキュア作品について尋ねても正確な情報を返せないことが確認されました。
この課題を解決するために、LLMに外部の知識を参照させる仕組み、RAG（Retrieval Augmented Generation）の考え方を取り入れました。具体的には、プリキュアに関する大量の文書（Wikipediaなどから収集・整理）を「ベクトル検索」できるようにデータベース化し、それをAI Agentが使える「ツール」として提供することにしました。このツールはMCP (Model Context Protocol) Serverとして実装しました。
文書をベクトル化（文章の意味を数値のまとまりに変換）する際には、使用するモデルによって検索精度が変わるため、いくつかのモデルを試しました。データベースに保存することで、AI Agentは質問や投稿内容に関連する文書を素早く探し出せるようになります。
AI Agentにこのツールを使わせるためには、「プリキュアに関する話題は確認してから話す」といった人格設定や、ツールの説明文に「正確な事実確認に使う」といったガイドを追加しました。これにより、AI Agentが自律的にツールを使うことを促しました。
実験の結果、AI Agentが自分でツールを使って正しい情報を取得し、投稿や返信を修正する成功例も生まれました。しかし、ツールを使わなかったり、期待と違う情報を取得してしまう失敗例も多く、LLMが自律的に外部ツールを適切に使いこなすのは難しい現状も見えました。これはLLM自体の性能や、ツールの活用を促すためのさらなる工夫（例えば、別のAIがチェックする仕組みなど）が必要であることを示唆しています。
今回、AI Agentが自ら判断して外部ツールを使い、正確な情報を基に投稿する一連の流れを実現できたことは大きな進歩です。この仕組みは、他の人格に別の専門知識を与える場合にも応用できます。今後、精度を上げて、AI Agentがリアルタイムの情報も参照できるようになれば、例えばアニメを一緒に見ながら感想を語り合う、といったこともできるようになるかもしれません。
引用元: https://memo.sugyan.com/entry/2025/06/05/090000
Gemini 2.5 ProGoogle DeepMindが、次世代AIシステムである「Gemini」ファミリーの最新モデル「Gemini 2.5 Pro」のプレビュー版を発表しました。これは、Geminiシリーズで最も高性能なモデルと位置づけられています。
Gemini 2.5 Proの主な特徴は以下の通りです。
高度な推論能力（Deep Think）: 最新の研究に基づいた「Deep Think」という強化された推論モードを導入しています。これにより、応答前に思考プロセスを深く掘り下げ、より高い性能と精度を実現しています。特に数学や科学の難しい問題で優れた成績を示しています。 進化したコーディング能力: コーディングタスクに非常に強く、Web開発に必要なコードを効率的に生成できます。コード生成や編集に関するベンチマークでも高いスコアを出しています。デモ動画では、プロンプト一つからインタラクティブなアニメーションやゲーム、データ可視化ツールなどをコーディングする様子が紹介されています。 ネイティブなマルチモーダル対応: テキストだけでなく、画像、音声、動画の入力を理解し、それらを組み合わせて処理することができます。 非常に長い文脈ウィンドウ: 100万トークンという広範な文脈ウィンドウを持ちます。これにより、非常に長い文書や大量のデータの中から関連情報を見つけ出し、複雑な分析を行うことが可能です。これは競合モデルと比較しても突出した能力です。 自然な音声出力（Native audio）: より表現力豊かで自然な音声出力を生成でき、24ヶ国語に対応しています。Google DeepMindは、Gemini 2.5 Proを含む最新モデルを、開発者がGoogle AI StudioやGemini APIを通じて利用できるように提供しています。これにより、開発者はこれらの強力なAIモデルを活用して、新しいアプリケーションやサービスを構築できます。
全体として、Gemini 2.5 Proは、推論、コーディング、マルチモーダル処理、長文理解といった様々な面で大幅な進化を遂げたモデルであり、日本のエンジニアの皆さんがAI開発に取り組む上で非常に強力なツールとなるでしょう。Google DeepMindは、こうしたAI技術を責任を持って、人類に beneficio (利益)をもたらす形で開発していくことを目指しています。
引用元: https://deepmind.google/models/gemini/pro/
初代スイッチ→スイッチ2で処理落ちが大幅改善との報告多数。さっそく試したユーザーから感動の声が続々。『ポケモンSV』『どうぶつの森』『ティアキン』などなど、いろんなゲームがぬるぬる動く新型ゲーム機「Nintendo Switch 2」が登場し、性能が向上したことで初代Switchソフトの動作が改善されたと話題です。『ポケモンSV』などで報告されていた処理落ちが大幅に減り、「ぬるぬる動く」「ロードが速い」といった喜びの声が多数上がっています。既存ゲームも新しいハードで快適に遊べるのは、技術の進化を感じられて面白いですね。
引用元: https://news.denfaminicogamer.jp/news/2506053j
お便り投稿フォームVOICEVOX:ずんだもん
-
関連リンク Stockmark-2-VL-100B：日本語に特化したドキュメント読解のためのChain-of-Thought視覚言語モデル
ストックマーク株式会社が、日本語のドキュメント理解に特化した新しいAIモデル「Stockmark-2-VL-100B」を開発し、公開しました。このモデルは、画像とテキストの両方を同時に理解できる「視覚言語モデル（VLM）」と呼ばれるもので、特に日本のビジネスでよく使われる、グラフや図が含まれたPDFやプレゼン資料などを正確に読み解くことを目指しています。
日本のビジネス文書は、文字だけでなく図や表、写真などが混ざっていることが多く、これらをまとめて理解するのはAIにとって難しい課題でした。Stockmark-2-VL-100Bは、このような文書から重要な情報を抽出し、質問に答えることができます。
このモデルの大きな特徴は、「Chain-of-Thought（CoT）」、つまり回答に至るまでの「思考過程」を詳細に示す能力を持っていることです。これにより、AIがなぜその回答を出したのか、どのような情報（画像やテキストのどこを見ればよいか）を根拠にしたのかが分かりやすくなります。これは、AIがもっともらしい間違った情報（ハルシネーション）を生成することを抑え、AIの回答の信頼性を高める上で非常に重要です。
このモデルは、国のGENIACプロジェクトの支援を受けて開発されました。1000億パラメータを持つ大きなモデルで、大規模な日本語データや、ビジネス文書に特化したデータを集めて、段階的に学習させることで高い性能を実現しています。特に、他の大規模なAIモデルを使って、日本語の高品質な学習データを新しく作り出した工夫も紹介されています。
開発されたモデルは、日本語のドキュメント読解に関する様々な評価データセットでテストされました。その結果、他の日本のVLMモデルを大きく上回り、特定のビジネスドキュメント読解タスクにおいては、GPT-4oよりも高い性能を示すことが確認されました。一般的な画像に関する質問応答でも高い性能を持っています。
今回発表された「Stockmark-2-VL-100B」モデルは、HuggingFace Hubで公開されており、誰でも利用できるようになっています。また、モデルの評価に使われたビジネススライドの質問応答データセット「BusinessSlideVQA」もGitHubで公開されています。
このモデルの登場は、日本のビジネス文書をAIでより正確に、そして信頼性高く処理する可能性を広げるものと言えるでしょう。
引用元: https://stockmark-tech.hatenablog.com/entry/2025/06/03/101007
やさしいClaude Code入門このSpeaker Deck資料は、KDDIアジャイル開発センターの御田稔さん（みのるんさん）による、「やさしいClaude Code入門」の発表内容をまとめたものです。主に、Anthropic社が提供する最新のLLM（大規模言語モデル）であるClaude 4と、そのコード生成に特化したAIエージェント「Claude Code」について、日本のエンジニア、特に新人の方に向けて分かりやすく解説しています。
まず、先日（2025年5月23日）リリースされたばかりのClaude 4に触れています。これはClaudeシリーズの最新モデルで、「軽量」なHaiku、バランスの取れたSonnet、パワフルなOpusなどのモデルがあります。Claudeシリーズ全体の特徴として、OpenAIやGoogle Geminiにも負けない高い賢さ、特にコーディング能力が地球最強クラスであること、そして安全性を重視しているため企業での利用にも向いている点が挙げられます。また、自然でこなれた日本語の生成が得意で、日本語の図表や写真の解釈も優秀とのことです。
次に本題のClaude Codeについて解説されています。Claude Codeは、Anthropicが提供するCLI（コマンドラインインターフェース）ベースのAIコーディングエージェント製品です。2025年2月にプレビュー版が登場し、Claude 4と同時に5月に正式リリースされました。この正式リリースで特に注目されたのが、VS Codeへの対応です。これにより、CLI操作のとっつきにくさが解消され、多くのユーザーが利用し始めています。
Claude Codeの大きな特徴は、コード生成に使われるLLMがClaudeであるため、生成されるコードの品質が非常に高いことです。CLIで指示を出しつつも、コードの編集結果はVS CodeなどのGUIで差分表示されるため、変更内容を確認しやすいのが利点です。また、To Doリストを自分で作って作業を進め、今何をしているのか報告してくれるなど、自律的な作業が得意です。作業中に質問や追加の依頼をしても、キリの良いところで対応してくれる賢さも持っています。Web検索も標準装備しており、最新情報に基づいた回答やコード生成が可能です。
既存のAIエディタと比べて、Claude Codeの最大のメリットはコストパフォーマンスです。なんと定額プラン（Claude Max）で最新のClaude APIを利用できるため、高性能なLLMを使う際に発生しがちな従量課金コストを抑えられます。サブスクせずにAPI課金することも可能です。また、同じClaude 4 APIを使う場合でも、本家AnthropicのClaude Codeはコード生成の品質がさらに高いという体感があるそうです。
使い方は非常にシンプルで、Node.jsをインストール後、npm install -g @anthropic-ai/claude-codeコマンドでパッケージをインストールし、ターミナルでclaudeと打つだけで起動できます。起動後は日本語で指示を出すことが可能です。VS Codeと連携することで、コードの変更差分を視覚的に確認しながら作業を進められます。
この資料は、最新の強力なAIツールであるClaude Codeが、エンジニアのコーディング作業をどのようにサポートしてくれるのか、その可能性をやさしく解説しています。最新技術に関心のある新人エンジニアにとって、AIを活用した開発の第一歩として非常に参考になる内容と言えるでしょう。
引用元: https://speakerdeck.com/minorun365/yasasiiclaude-coderu-men
Anthropic、5カ月で売上高が3倍に–急成長の背景にあるものはAIスタートアップ企業のAnthropicが、わずか5カ月という短期間で年間売上高を3倍にし、30億ドル（約4700億円）に達したというニュースです。これは、企業が生成AIツールをビジネスで活用することへの関心が非常に高まっていることを示しています。
Anthropicは、2021年にOpenAI出身のメンバーを中心に設立されました。彼らは、AIの「安全性」や「責任ある開発」を重視する考え方を創業当初から掲げており、多くの研究者がこの理念に共感して集まっています。
ビジネスの中心は、企業向けの生成AIチャットボット「Claude」ファミリーです。Anthropicは、企業が安心してAIを使えるように、プライバシーやデータセキュリティに特に力を入れています。例えば、ユーザーが明示的に同意しない限り、入力したデータをAIモデルの学習に利用しないという方針を採っています。これは、ビジネスでAIを導入する際に重要視されるポイントの一つです。
Anthropicは技術開発も進めており、最新モデルの「Claude Opus 4」はコーディング能力が高いと評価されています。このような技術力と安全性への配慮が、多くの企業に支持され、驚異的な売上増加につながったと考えられます。
今回のAnthropicの急成長は、生成AIが企業活動に深く浸透し、ビジネスを変革する力を持っていることを改めて示す出来事です。そして、ただ高機能なだけでなく、「安全性」や「信頼性」がビジネスでAIを選ぶ上で非常に重要な要素になってきていることが分かります。
一方で、AIの進化が雇用に影響を与える可能性についても議論されています。AnthropicのCEOは、将来的にAIが特定の仕事の一部を代替したり、少人数のチームがAIを活用して大きな事業を立ち上げたりする可能性に言及しています。新しい技術であるAIが、これから社会や働き方をどう変えていくのか、エンジニアとして注目していく価値のある動向と言えるでしょう。
引用元: https://japan.zdnet.com/article/35233736/
iPhoneを中に投入すると”小さなクリーンルーム”で画面保護フィルムを貼ってくれる自動販売機が登場！「不器用なのでこれはアリ」iPhoneの保護フィルム貼りに失敗しがちな人向けの自動販売機「フィルラボ」が登場しました。iPhoneを入れると、機械の中で小さなクリーンルームのような環境を作り、ホコリや気泡を抑えながら画面クリーニングとフィルム貼りを約2分で完了します。手作業の煩わしさを解消する、ユニークなテクノロジーの活用事例として注目されています。
引用元: https://togetter.com/li/2559302
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク AIに「分からない」と言わせるための「RAG」の手法
RAG（Retrieval Augmented Generation）は、AIが学習済みデータから得た知識（内部知識）に加え、外部の情報源から検索した情報（外部知識）も参照して回答を生成する技術です。これにより、AIはより正確な情報に基づいた回答を出せるようになります。
しかし、従来のRAGや、さらに工夫を凝らした手法（Astute RAG、RAFTなど）を使っても、AIは回答に必要な情報が内部にも外部にもない場合でも、もっともらしいが実際は誤った情報を作り出してしまう「ハルシネーション（もっともらしいが、実際は誤った情報を生成してしまうこと）」を起こすことがあります。これは、AIが自分の知識の限界を正確に判断するのが難しいためです。
特に、高い信頼性が求められる分野でAIを利用する場合、ハルシネーションは大きな問題となります。そこで注目されているのが、新しい手法「DTA（Divide-Then-Align）」です。この手法の目的は、AIが本当に分からないことには、正直に「分かりません」と答えられるようにすることです。
DTAのポイントは、AIが「分からない」と答えるべき状況を明確に定義し、それを学習させる点にあります。質問に対して、AIが持つ知識で答えられるか、そして外部情報に答えがあるか、という2つの観点からデータを分類します。そして、AIも外部情報も答えを持っていないケース（本当に分からない状況）での「分かりません」という回答を「正しい回答」として学習させることで、AIに知識の境界線を認識させ、「これは答えられない」と判断できるようにします。
このDTA手法を適用した結果、従来のRAGモデルと比較して、回答の正確さを保ちながら、「分からない」と適切に答える能力が大幅に向上することが示されました。特に、知識が全くない状況での正直さが大きく改善されています。
企業向けにAIシステムを提供する場面では、ユーザーがハルシネーションを一度経験すると、AIへの信頼を失ってしまうことがよくあります。そのため、AI自身が知識の限界を理解し、正直に振る舞うことは、AIシステムを広く普及させる上で非常に重要です。今後、様々な種類の情報を取り込むRAGが増えていく中で、DTAのような、AIが「分からない」と言えるようにする技術は、システム開発の重要なポイントとなるでしょう。RAGシステムを開発する際の選択肢として、この考え方が参考になれば幸いです。
引用元: https://zenn.dev/knowledgesense/articles/468d7c853901f8
No GPU left behind: Unlocking Efficiency with Co-located vLLM in TRL大規模言語モデル（LLM）の学習手法の一つにGRPOというものがあります。これはモデルが自分で文章などを生成し、その結果をもとに学習を進める方法です。この「生成」のステップが学習全体の処理速度（スループット）を遅くする原因（ボトルネック）になることがあります。
Hugging FaceのTRLライブラリでは、この生成ステップを高速化するためにvLLMという技術を利用しています。しかし、これまでは学習を行うGPUとvLLMが動作するGPUを別々に用意する必要がありました（これを「サーバーモード」と呼びます）。この方式では、学習中にvLLMのGPUが待機したり、逆に生成中に学習用のGPUが待機したりと、お互いがアイドルになる時間が多く発生し、GPUリソースの無駄が多く、コストも高くなりがちでした。
この問題を解決するため、TRLに新しく「コローケーションモード」が追加されました。これは、学習とvLLMによる生成を「同じGPU」で実行できるようにする技術です。これにより、学習と生成が同じGPU上で順番に処理されるため、GPUのアイドル時間を大幅に削減できます。また、別々のプログラムとして通信する必要がなくなり、処理のオーバーヘッドも減ります。
実験の結果、コローケーションモードは従来のサーバーモードと比較して、GPUを効率的に使用し、全体の処理速度を向上させることが確認されました。特に、一度に多くのデータを処理する場合や、比較的大きなモデルを扱う場合に効果が高いことが示されています。さらに、非常に大きなモデル（72Bパラメータ）でも、vLLMのGPUメモリ解放機能（sleepモード）や、モデルをGPU間で分散させるDeepSpeed ZeRO Stage 3といった技術と組み合わせることで、コローケーションモードで効率よく学習できることが確認されました。
コローケーションモードは、GPUリソースを最大限に活用し、LLMの学習をより速く、効率的に進めるための重要な進歩です。開発中に技術的な課題もありましたが、モデルの学習品質を維持したまま効率を上げられることが大きな利点です。
引用元: https://huggingface.co/blog/vllm-colocate
Claude 4(Opus・Sonnet)とは？使い方や料金プロンプトのコツを解説Anthropic社から、新しい高性能AIモデル「Claude 4」が登場しました。これは「モデルファミリー」として提供され、特に「Opus」と「Sonnet」という主要なモデルがあります。日本の新人エンジニアの皆さんがAIの選定や活用を考える上で、このClaude 4を知っておくと役立ちます。
「Claude 4 Opus」は最も賢く高性能なフラッグシップモデルで、特に複雑なコーディングや高度な推論、長期的なタスクが得意です。一方、「Claude 4 Sonnet」は高性能ながらも応答速度が速く、コスト効率が良いバランスの取れたモデルです。普段の業務や簡単な開発支援にはSonnet、より難易度の高い課題にはOpusと使い分けるのがおすすめです。無料ユーザーでもSonnetの一部機能は試せます。
Claude 4の大きな特徴は、その高いコーディング能力です。特にOpusは「世界最高のコーディングモデル」を目指しており、GitHubのIssue解決のような実際の開発タスクで高い精度を示しています。Sonnetも大幅に進化し、GitHub Copilotの基盤モデルにも採用されています。
また、賢く考えるための新しい仕組みもあります。質問に応じて素早く答えるモードと、時間をかけてじっくり考える「拡張思考モード」があり、このモードではWeb検索などの外部ツールも使ってより正確な答えを出すことができます（ベータ版）。開発者が許可すれば、過去のやり取りやファイル内容を「メモリ」として覚えておける機能も進化し、長期的なプロジェクトでの一貫性が向上しました。
開発者向けには、「Claude Code」というツールも登場しました。これはVS CodeやJetBrainsなどの開発環境（IDE）と連携してコード作成や修正を助けてくれます。SDKを使えば独自のAIエージェントを開発したり、GitHub連携でコードレビューや修正を自動化したりといったことも可能になりました。APIも強化され、モデルにコードを実行させたり、外部システムと連携させたりする機能が追加されています。
他の主要なAIモデル（GPT-4.1やGemini 2.5 Proなど）と比較すると、Claude 4はコーディングや推論のベンチマークで高いスコアを出しており、これらの分野で強みを持っています。ただし、画像や音声なども扱うマルチモーダル機能では他のモデルが進んでいる部分もあります。どのモデルを選ぶかは、皆さんがどんな作業にAIを使いたいかによって最適なものが変わってきます。
Claude 4は、公式ウェブサイト（claude.ai）で手軽に試せるほか、CursorエディタやGitHub Copilot、主要なクラウドプラットフォーム（Google Cloud Vertex AI, Amazon Bedrock）からも利用できます。
AIを効果的に使うには、プロンプト（AIへの指示）の仕方が重要です。Claude 4に明確で具体的な指示を与え、目的や背景を伝え、期待する出力形式を示すことで、より良い結果が得られます。例を見せたり、XMLタグを使ったりといった工夫も効果的です。
Claude 4は、開発作業の効率化や新しいアイデアの実現を助けてくれる強力なツールです。まずは無料版のSonnetを試してみて、その能力に触れてみることをお勧めします。
引用元: https://www.ai-souken.com/article/what-is-claude4
「ミクちゃんネギ買ってきて、卵があったら６つお願い」と頼んだらネギを６本買ってくるのは間違ってるけど間違ってないマンガがおもろいプログラミングの条件分岐ミスをネタにしたマンガが話題。エンジニアがよくやる間違いとして共感を集めています。「卵があったら」を「卵は6個」と解釈してしまう思考回路が面白いと、コード例とともに盛り上がっています。
引用元: https://togetter.com/li/2558745
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク MCPにおけるセキュリティ考慮事項と実装における観点（後編）
この記事は、生成AIと外部の機能（ツールやデータ）を連携させるための技術仕様であるMCP（Model Context Protocol）のセキュリティについて、攻撃者の視点と、MCP Serverを提供する開発者が取るべき対策を中心に解説しています。前編では利用者の視点からセキュリティを考えましたが、後編では開発・運用側の視点に立ちます。
なぜMCPのセキュリティが重要かというと、MCP Serverは実行環境上でファイル操作やコマンド実行、外部サービスとの通信など、比較的広い権限を持って動作することが多いため、攻撃者に狙われやすいからです。攻撃されると、機密情報が盗まれたり、クラウド上のリソースを勝手に操作されたり、ひどい場合はシステムを踏み台にされてマルウェアを拡散されるといった被害が起こりえます。
攻撃者は主にMCPを構成する部分（生成AIアプリ、連携部分、サーバー）やその実行環境を狙います。具体的には、ユーザーに悪意のあるMCP Serverを誤って実行させたり、MCP Serverが利用する外部のデータを汚染したり、ファイルに仕込んだ見えない命令を使って意図しない操作をさせたりします。また、Streamable HTTP形式で動作するMCP Serverに対しては、ブラウザの仕組みを悪用したり、認証・認可が不十分なサーバーに直接アクセスしたりといった手口も考えられます。
これらの脅威に対し、開発者が行うべき基本的な対策はいくつかあります。まず、一般的なWebアプリケーションと同じように、ユーザーからの入力値（ファイルパスやURLなど）をしっかり検証・無害化し、Path TraversalやSSRF、コマンドインジェクションといった脆弱性を防ぐことが重要です。また、MCP特有の対策として、Toolの説明などをそのまま生成AIのプロンプトに含めず構造化情報として渡す工夫や、Tool実行時にはユーザーに確認を求める仕組みを入れることで、意図しない機能実行を防ぐことができます。
Streamable HTTP形式でローカルで動かす場合は、外部からアクセスされないようにlocalhostのみにバインドすること、Originヘッダで通信元を確認すること、不要なCORS設定をしないことが対策になります。もしMCP Serverをリモートで公開する場合は、通信をHTTPS化し、アクセス制御（IP制限や認証/認可）をしっかり導入することが必須となります。特に認可にはOAuth 2.1に準拠した仕組みを導入し、外部サービスとの連携時にはSession Bindingを考慮した安全な実装が必要です。
MCPのセキュリティ対策はまだ発展途上であり、新しい攻撃手法も出てくる可能性があります。記事の付録には実装者向けのチェックリストも載っているので、ぜひ活用しながら、常に最新の情報をキャッチアップして安全なMCPの実装・運用を目指しましょう。
引用元: https://blog.flatt.tech/entry/mcp_security_second
Beyond the Black Box: Interpretability of LLMs in Financeこの論文は、金融分野で活用が広がる大規模言語モデル（LLM）の「解釈可能性」、つまり「なぜAIがその結果を出したのか」を理解することの重要性とそのための技術について論じています。
LLMは現在、金融業界において、レポート作成、顧客対応チャットボット、市場センチメントの分析、規制遵守のチェック、投資アドバイス、情報の検索や要約など、様々なタスクで優れた能力を発揮しています。しかし、LLMは非常に複雑な構造を持つため、内部の動作原理が分かりにくい「ブラックボックス」状態になりやすいという大きな課題があります。
金融業界は、その性質上、極めて厳格な規制があり、システムに対する高いレベルの透明性、公平性、そして何か問題が起きた際に責任を明確にするための説明責任が不可欠です。「AIがなぜその判断を下したのか」を説明できなければ、特に人の財産や重要な判断に関わる場面で、安心して利用することが難しいのです。
この論文では、この課題を解決するために、「機構的解釈可能性（Mechanistic Interpretability）」という比較的新しい技術アプローチを、金融分野で初めて応用した事例として提示しています。機構的解釈可能性とは、LLMの内部構造や動作を文字通り「分解して逆さまに調べる」ことで、モデルがどのように情報を処理し、特定の振る舞いを生み出しているのかを最も分かりやすく理解しようとする手法です。モデルの内部にある情報の流れや処理のまとまり（「回路」と呼ばれることもあります）を詳細に分析することで、「なぜ」特定の予測や応答が生まれたのかを深く理解できます。そして、単に理解するだけでなく、モデルの望ましくない振る舞いを特定し、修正するための手助けにもなります。
論文では、この機構的解釈可能性の理論的な側面を解説しつつ、トレーディング戦略における意思決定プロセスの理解、市場センチメント分析での根拠特定、さらにはAIが持つ可能性のある偏り（バイアス）や事実に基づかない情報（ハルシネーション）の検出といった、金融分野における具体的な様々な応用例とその実験結果を示しています。
機構的解釈可能性はまだ開発途上の技術ですが、LLMの金融分野への浸透が進むにつれて、その重要性はますます高まると予測されています。このような高度な解釈可能性の技術は、AIシステムが常に倫理的であり、透明性を保ち、厳格な金融規制に適合し続けるために不可欠なツールとなるでしょう。論文の著者らは、特に金融規制やコンプライアンスの観点から、これらの技術が現在のニーズだけでなく、将来の世界の金融規制当局からの期待にも応えうる可能性を強調しています。
この研究は、LLMを金融のような信頼性が極めて重要な分野で、安全かつ責任を持って利用するための技術的な基盤を築く一歩と言え、AIの信頼性向上に関心のあるエンジニアにとって注目すべき内容です。
引用元: https://arxiv.org/abs/2505.24650
PythonとOpenAI APIで実践！はじめてのMCP開発入門【第10回】MCP活用プログラミング(2) - 会話履歴コンテキストで文脈を維持する「インテリジェント・チャットボット」の基礎この記事は、PythonとOpenAI APIを使って、会話の内容を覚えて自然な対話ができるチャットボットを作るための基礎を解説しています。新人エンジニア向けに、チャットボット開発で非常に大切な「会話履歴の管理」について、分かりやすく説明されています。
チャットボットは、特別な設定をしないと、以前のやり取りを忘れてしまいます。例えば、「今日の天気は？」と聞いた後に「傘はいる？」と聞いても、「どこの天気？」と聞き返されてしまうことがあります。これは、AIがそれぞれの質問を独立したものとして扱ってしまうためです。
そこで重要になるのが「会話履歴」です。過去の会話をAIに伝えることで、AIは文脈を理解し、一貫性のある、より人間らしい応答ができるようになります。この記事では、この会話履歴をAIに伝えるためのOpenAI APIの標準的な形式であるmessages配列について詳しく解説しています。
messages配列は、AIにチャットボットとしての役割やルールを伝えるsystemメッセージ、ユーザーの入力であるuserメッセージ、そしてAI自身の応答であるassistantメッセージを順番に並べたリストです。新しいユーザー入力があるたびに、このリスト全体をAPIに送ることで、AIはこれまでの会話を「記憶」します。
記事では、Pythonを使ってこのmessages配列を管理（「ステート管理」と呼びます）し、簡単なコマンドラインチャットボットを実装する具体的なコード例も紹介されています。リストを使って会話履歴をどんどん追加していくイメージです。
ただし、会話が長くなると、送る履歴の量（トークン数）が増え、APIの費用が高くなったり、応答が遅くなったり、さらにはAIが一度に処理できる上限（「コンテキストウィンドウの限界」といいます）を超えてしまったりする課題が出てきます。この記事の最後に、この課題に対する「スライディングウィンドウ」や「会話の要約」といった、より進んだ対策の考え方も触れられています。
要するに、会話履歴を適切に管理してAPIに渡すことが、自然な対話ができるチャットボット開発の鍵であり、その基本的な方法と課題、そして今後の発展の方向性が学べる入門記事です。
引用元: https://qiita.com/QueryPie/items/ee937f939a186d3137c8
幸坂謙之介、「14才の証明 (feat. 東北きりたん, 東北ずん子, 東北イタコ, ずんだもん & めろう)」を配信開始｜THE MAGAZINE幸坂謙之介さんが、東北きりたんさん、東北ずん子さん、東北イタコさん、ずんだもんさん、めろうさんをフィーチャリングした新曲「14才の証明」の配信を開始しました。この記事は、その新曲が主要な音楽配信サービスで聴けるようになったことを伝えるニュースです。プログラミングやAI関連でも見かける「ずんだもん」が楽曲に参加しているのは面白いですね。新しい技術やキャラクターが様々な分野で活躍する例として、ちょっと息抜きに聴いてみるのも良いかもしれません。
引用元: https://magazine.tunecore.co.jp/newrelease/513439/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Cerebras beats NVIDIA Blackwell: Llama 4 Maverick Inference
このニュースは、AIモデルを使ったサービスの「速さ」、特に「推論速度」に関する重要な進歩を伝えています。推論速度とは、AIに何か指示を与えたときに、どれだけ早く回答や結果を出してくれるかのスピードのことです。この速さは「トークン/秒（TPS）」という単位で測られます。トークンは文章の単語や記号のまとまりのようなもので、TPSは1秒間に生成できるトークンの数を表します。
今回、アメリカのCerebrasという会社が、Metaが開発した大規模AIモデル「Llama 4 Maverick」（400Bというパラメータ数のモデル）の推論速度で、世界記録を達成しました。独立機関であるArtificial Analysisが行ったベンチマークテストによると、Cerebrasは2,522 TPS以上を記録しました。これは、同じテストでNVIDIAの最新GPUである「Blackwell」が記録した1,038 TPSを大きく上回る速度です。他の主要ベンダーと比較しても、Cerebrasが最も速い結果となりました。
なぜ推論速度が速いと良いのでしょうか？最近の高度なAIアプリケーション、例えばAIがプログラムコードを自動で書いたり、複雑な問題を段階的に推論したりするような場合、AIは多くの情報を処理し、長い文章を生成することがあります。このとき推論速度が遅いと、ユーザーは応答を長時間待たされることになり、AIを実用的に使う上で大きな課題となります。速度が速ければ速いほど、AIはスムーズに動き、より快適に利用できるようになります。
Cerebrasの成果の注目すべき点は、この記録的な速さを特別なソフトウェアの最適化に頼らずに達成したこと、そしてそのハードウェアとAPIが既に利用可能であることです。一方、NVIDIAのベンチマーク結果はカスタム最適化によるものであり、一般的に利用できるサービスではまだその速度が出ていない状況も指摘されています。
今回のCerebrasの発表は、大規模AIモデルの性能を向上させる上で重要な「速さ」の面で新たな基準を示したものであり、これからのAI活用の可能性を広げる一歩と言えるでしょう。
引用元: https://www.cerebras.ai/press-release/maverick
When Fine-Tuning Actually Makes Sense: A Developers Guideこの記事は、LLM（大規模言語モデル）を開発する上で、ファインチューニングがどのような場合に役立つのか、その具体的なメリットと始め方について、開発者向けに解説しています。
AIモデルの能力を引き出すためにプロンプトを工夫することは重要ですが、プロンプトだけでは限界がある場合があります。例えば、出力形式（JSONなど）が安定しない、プロンプトが長くなりすぎてコストや速度が悪化する、モデルに特定の細かいルールや振る舞いを教えたい、といった問題です。このような、プロンプトでは解決しきれない具体的な課題に対して、ファインチューニングは非常に有効な手段となります。
ファインチューニングを行うことには、主に以下のようなメリットがあります。
タスク品質の向上: 特定のタスクに対するモデルの精度や、出力のスタイル、JSONやXMLのような特定のフォーマットを正確に生成する能力を大幅に改善できます。 コスト削減と高速化: ファインチューニングにより、同じタスクをより短いプロンプトや、より小さなモデルで実行できるようになります。これにより、推論にかかるコストを抑え、処理速度を向上させることが可能です。小さなモデルは、個人のPCやデバイス上で動かすことも容易になり、データのプライバシー保護にもつながります。 ルールやロジックの遵守: モデルに特定の条件に基づいた応答や複雑なルールに従わせる能力を高められます。期待しない振る舞い（バグ）を修正するためにも利用できます。 ツール利用の精度向上: モデルが外部ツールを適切に判断し、正確なフォーマットで利用する能力を高めることができます。ただし、知識の追加を目的とする場合は、ファインチューニングは最適な方法ではありません。最新情報や特定の知識をモデルに参照させたい場合は、RAG（外部情報参照）や、プロンプトに直接コンテキストとして情報を含める方法の方が適しています。
ファインチューニングを始める際は、まず「何を解決したいのか」という具体的な目標を明確にすることが大切です。その目標に合わせて、どのベースモデルを使うかを選びます。少量でも良いので学習データを用意し、実際に学習させて結果を評価し、改善を繰り返していくのが基本的な流れです。
このように、ファインチューニングは、プロンプトだけでは実現が難しいAIモデルのカスタム化や性能改善のための強力な手法です。特定の問題に直面しているエンジニアにとって、試す価値のある技術と言えるでしょう。
引用元: https://getkiln.ai/blog/why_fine_tune_LLM_models_and_how_to_get_started
Why DeepSeek is cheap at scale but expensive to run locallyDeepSeekのような大規模言語モデル（LLM）が、なぜサービスとして大規模に提供されると安価で高速なのに、自分のパソコンなどローカル環境で動かすと遅く高価になるのか、という疑問について技術的な観点から解説しています。
その主な理由は、AI推論を行う際の「スループット」（単位時間あたりに処理できる量）と「レイテンシ」（応答速度、待ち時間）の間に存在するトレードオフにあります。このトレードオフは、推論処理の際に「バッチサイズ」（複数のユーザーからのリクエストをまとめて一度に処理する数）をどう設定するかによって生じます。
GPUは、多数の計算をまとめて大きなひとつの行列計算（GEMM）として行うのが非常に得意です。これに対し、小さな行列計算を何度も繰り返すのは苦手です。バッチ推論では、複数のユーザーからのリクエストをまとめて大きなバッチとしてGPUに投入します。これにより、個々のリクエストをバラバラに処理するよりも、GPUを効率的に使い、全体としての処理能力（スループット）を大幅に向上させることができます。
しかし、このバッチ処理には待ち時間が伴います。例えば、「バッチサイズ128」で処理すると決めた場合、リクエストは128件分集まるまで待機キューで待つことになります。バッチサイズが大きいほど、GPUの利用効率は上がりスループットは向上しますが、個々のユーザーの応答が返ってくるまでの時間（レイテンシ）は長くなります。逆にバッチサイズが小さいとレイテンシは短くなりますが、GPUが非効率になりスループットは低下します。
特にDeepSeek-V3のような「Mixture-of-Experts (MoE)」と呼ばれるアーキテクチャを持つモデルや、層が多く大規模なモデルは、その構造上、GPUの効率的な利用のために大きなバッチサイズがほぼ必須となります。MoEモデルは多数の「専門家」を持っており、大きなバッチで処理しないと、各専門家が担当する計算量が少なくなり、GPUが非効率になります。また、多層モデルはGPUを複数使って処理をパイプライン化しますが、バッチサイズが小さいとGPU間の待ち時間（パイプラインバブル）が発生しやすくなり、これも非効率の原因となります。
そのため、DeepSeekのようなモデルは、多くのユーザーからの同時リクエストがある大規模なサービス環境では、大きなバッチサイズで効率的に実行できます。しかし、ローカル環境で一人のユーザーが使う場合、バッチサイズが非常に小さくなるため、GPUが非効率になり、結果として処理が遅く感じられるのです。
OpenAIやAnthropicのモデルが比較的応答が速いのは、アーキテクチャが異なるか、推論効率を高める特別な技術を使っているか、あるいはGPUを大量に投入して低レイテンシを実現している可能性があると推測されています。
このバッチ処理によるスループットとレイテンシのトレードオフは、LLMの運用コストや性能を理解する上で重要な考え方です。
引用元: https://www.seangoedecke.com/inference-batching-and-deepseek/
VTuber×声優が初の生共演！原宿で朗読劇「ずんだもんとつむぎのバーチャル大冒険」6月開催VTuberと声優が舞台で初めて生共演する朗読劇が6月に原宿で開催されます。「ずんだもん」の声優さんや、VTuberの春日部つくしさんらが出演。リアルタイムでキャラクターを動かす技術を使った「ハイブリッド演劇」として注目されています。新しいエンタメ技術に興味のある新人エンジニアさんは要チェックです。
引用元: https://hotakasugi-jp.com/2025/06/01/stage-news-zundamon-kasukabetsukushi/
お便り投稿フォームVOICEVOX:春日部つむぎ
-
関連リンク AIエージェントで並列実装なら必須技術！ Git Worktree を理解する
最近はClaude CodeやGitHub CopilotなどのAIツールを使って開発する機会が増えてきましたね。これらのAIは複数の作業を同時に進めるのが得意ですが、私たちエンジニアが使うGitのやり方には、少し困ったところがあります。
従来のGitでは、別の作業（例えば、新しい機能開発中に緊急のバグ修正が入るなど）を始めるたびに、今やっている作業を一時的に保存して、ブランチという作業場所を切り替える必要がありました。これが結構面倒で、作業が中断されたり、開発環境を再準備する必要があったりします。特にAIエージェントに長時間作業を任せている場合、ブランチを切り替えるとAIが混乱してしまうこともあります。
そこで注目されているのが「Git Worktree」という機能です。これは、同じプロジェクトの様々なブランチを、まるで別のプロジェクトのように、異なるフォルダーで同時に開いて作業できるようにする機能です。例えるなら、一つの本棚（Gitリポジトリ）にある複数の本（ブランチ）を、いくつかコピーして別々の机（Worktree）に置いて、同時に読み進められるようなイメージです。
Git Worktreeを使えば、例えば一つのフォルダーでAIに大きなリファクタリング作業を任せている間に、別のフォルダーで自分自身が別のバグ修正を進める、といった並列作業がスムーズにできます。それぞれの作業場所は完全に分離されているので、AIの作業と自分の作業が干渉する心配もありません。
記事では、Claude Codeの公式ドキュメントでもWorktreeを使った並列作業が推奨されていることや、VS Codeという開発ツールでWorktreeの管理を簡単にする拡張機能「Git Worktree Manager」が紹介されています。
Git Worktreeは、AIエージェントを活用した並列開発を進める上で、とても便利な技術です。これまでのGitのやり方では難しかったマルチタスク開発が、Worktreeを使うことで効率的に行えるようになるでしょう。ぜひ試してみてください。
引用元: https://zenn.dev/siu_issiki/articles/git_worktree
Coding Agentをこれから導入するならClaude Code Actionが個人的におすすめこの記事は、イオンネクストで技術戦略を担当されている筆者が、GitHub上で動くAIコーディングアシスタント「Claude Code Action（Vertex AI版）」を使ってみた感想や導入方法のポイント、他のAIツールとの比較を紹介しています。
なぜエンタープライズ（企業での利用）でGoogle Cloud (Vertex AI) がおすすめかというと、既存のクラウド環境にAIツールの費用を混ぜ込めるため、新しいツール導入の手間やハードルが下がるからです。アカウント管理も既存の仕組みに乗れるので楽だとしています。Vertex AIでは、GeminiやClaudeだけでなく、NotebookLM Enterpriseなど評判の良いAIツールを導入しやすい点もメリットに挙げています。
Claude Code Actionは、GitHubワークフローに組み込むことで、自動コードレビューやPR（プルリクエスト）管理、課題分類などがAIでできるようになる機能です。Anthropicが提供しており、AIモデルとしてAWS BedrockやGoogle Cloud Vertex AIを利用できます。
Vertex AIでClaude Code Actionを使うための設定手順は、基本的に公式ドキュメント通りでOKですが、いくつかの修正点があったそうです。例えば、GitHub ActionsのYamlファイルで参照するアクションのパスや、AIモデルの指定方法などに変更が必要だった点を共有しています。
他のCoding Agentとして、GitHub Copilot Coding AgentやDevinと比較したところ、それぞれ違いが見られました。GitHub Copilot Coding Agentは、すぐにDraft PRを作成し、実行計画もPRの説明として詳細に示され、コードも正常に動作したそうです。READMEやヘルパースクリプトも自動で追加されるなど、気が利いている印象だったとのこと。一方、Claude Code Actionは、Issueへのコメントを起点に実行計画を立て、ユーザーがPRを作成する流れでした。試した際のコードはAPIエラーで動きませんでした。Devinは、PRは作成しましたが、基本的な機能テストを実施済みと記載されているものの実際はテストしておらず、作成されたコードも引数に問題があり動きませんでした。ただし、普段のDevinの品質は良い印象とのことです。
PRレビューツールとしては、Copilot Code ReviewとClaude Code Action（レビュー用にプロンプト調整）を比較しました。Copilot Code Reviewは、通常のPRレビューのように該当行へのコメントやSuggested change（修正案）を出してくれる点で使いやすいと感じたそうです。Claude Code Actionは、プロンプト次第ですが、どのコードへの指摘か視覚的に分かりづらい場合があったものの、指摘内容自体はCopilotと同様の箇所を捉えていました。
まとめとして、Claude Code Actionは他のツールと比較しても実用的な品質であり、プロンプトの調整やナレッジの蓄積でさらに精度が向上する可能性を述べています。エージェント型AIの導入コストにハードルを感じる企業は、まずはClaude Code ActionとVertex AI/Bedrockの組み合わせで試してみるのが良い選択肢となり得ると提案しています。ただし、Vertex AIは従量課金のため、コスト管理は必要です。
引用元: https://zenn.dev/aeonpeople/articles/1ec37f3ae91995
RAG(検索拡張生成)を用いるLLMアプリにおける、セキュリティ視点での実装ガイドラインLLM（大規模言語モデル）は進化していますが、最新情報や固有の知識には弱点があります。この課題を解決する技術がRAG（検索拡張生成）です。RAGは、あらかじめ用意した資料（知識ベース）の中から、ユーザーの質問に関連する部分を検索し、その情報をLLMに与えることで、より適切で正確な回答を引き出します。
RAGアプリを開発する際、その便利さからセキュリティが後回しになりがちですが、いくつかの重要なリスクが存在します。この記事では、特にRAG特有のリスクと対策に焦点を当てて解説しています。
RAGアプリのセキュリティリスクはいくつかありますが、特に気をつけたいのは以下の点です。
データ汚染: 知識ベースに攻撃者が悪意のある情報を混ぜ込むリスクです。これにより、LLMが間違った情報や有害な情報を回答してしまう可能性があります。これは「Data Poisoning」とも呼ばれ、多くのユーザーに影響するため深刻です。 機密情報の漏洩: 知識ベースに会社の非公開情報などがある場合、アクセス権限が正しく設定されていないと、本来その情報を見られないはずのユーザーが見てしまうリスクです。特に複数の会社やユーザーで共有するシステム（マルチテナント）では、他のユーザーのデータが見えないようにする「認可制御」が非常に重要になります。 過剰な課金: LLMの利用料金は、処理するテキスト量（トークン数）によって決まることが多いです。攻撃者が大量のリクエストを送るなどして、意図的に料金を増やしてしまうリスクがあります。RAGは知識ベースの情報もLLMに渡すため、通常よりもトークン数が多くなりやすく、このリスクに注意が必要です。これらのリスクのうち、特にRAGで重要な役割を果たすVector store（知識ベースをベクトル形式で保存・検索するデータベース）に関連するデータ汚染とデータ漏洩について詳しく解説されています。
Vector storeの「データ汚染」を防ぐには、知識ベースに入れるデータの信頼性を確認することが基本です。外部からデータを取り込む場合は、信頼できる情報源かを確認したり、データの種類でフィルタリングしたりといった対策が有効です。
Vector storeからの「データ漏洩」を防ぐには、先ほどの「認可制御」が鍵となります。マルチテナント環境では、ユーザーごとにアクセスできるデータを厳密に分ける必要があります。この認可制御の実装方法は、利用するVector storeのライブラリによって異なります。ライブラリによっては、マルチテナントに対応した機能が備わっているものや、データを区別するための情報を付けて検索時に絞り込む方法（metadata filtering）で対応できるものがあります。metadata filteringを使う際は、悪意のある入力を防ぐための対策（サニタイズなど）をしっかり行う必要があります。独自の認可制御を実装するとミスが発生しやすいため、可能な限りライブラリの機能を利用するか、専門家のレビューを受けることが推奨されます。
RAGアプリ開発では、その機能性だけでなく、データ汚染や情報漏洩といったセキュリティリスクを理解し、適切な対策を講じることが、安全なシステムを構築するために不可欠です。
引用元: https://blog.flatt.tech/entry/rag_security
NTTからサイバー攻撃に対するセミナーの案内がきたが、自分がいま取り組んでるのは、「アライグマから光ファイバーをどう守るか？」 物理攻撃には、めっぽう弱いのIT化社会NTTからサイバー攻撃セミナーの案内が来たものの、現場では「アライグマから光ファイバーケーブルを守る」という物理的な課題に取り組んでいるツイートが話題に。ITインフラはサイバー攻撃だけでなく、動物による物理的な被害対策も意外と重要であることをユーモラスに伝えています。過去にはセミやリスの対策もあり、システムの安定稼働には様々な視点が必要だと分かりますね。
引用元: https://togetter.com/li/2556533
お便り投稿フォームVOICEVOX:ずんだもん
-
関連リンク Large Language Model Agent: A Survey on Methodology, Applications and Challenges
この資料は、LLM（大規模言語モデル）の能力向上に伴い注目度が高まっている「LLMエージェント」に関する、最新の研究動向や応用例、そして技術的な課題をまとめたサーベイ資料です。LLMエージェントとは、ユーザーからの指示を受け、環境を認識し、自分で考えて行動を計画・実行することで、タスクを自律的に達成するAIシステムのことです。従来のAIシステムが事前に決められた応答をするだけだったのに対し、LLMエージェントはより複雑な問題に対応し、継続的に学習して賢くなる点が異なります。その進化の鍵は、高い推論能力、外部ツールを利用する能力、そして過去の情報を覚えておく記憶力にあります。
このサーベイ資料では、LLMエージェントの研究開発を体系的に整理しています。まず、エージェントをどうやって「構築」するかについて説明されています。これには、エージェントの役割や個性（プロファイル）の設定、過去のやり取りや知識を保存・利用する「メモリ機構」、複雑なタスクをステップごとに分解して解決策を考える「計画能力」、そして計算ツールや外部APIなどを使って実際に行動を起こす「行動実行」といった技術要素が含まれます。
次に、複数のLLMエージェントが協力してより大きなタスクに取り組む「協調」の仕組みが紹介されています。タスクを割り振る中心的なエージェントがいる構成や、エージェント同士が直接話し合って問題を解決する構成など、様々な協力のアーキテクチャが研究されています。
さらに、LLMエージェントが自律的に「進化」していくためのアプローチも解説されています。これは、人間からのフィードバックなしに自分で学習を進めたり、自分の出した結果を「反省」して修正したり、目標達成度を自分で評価して改善したりする方法（自己最適化・自己学習）や、他のエージェントとの協力や競争を通じて互いを高め合う仕組み（マルチエージェント共進化）です。
また、LLMエージェントの性能を適切に評価するための「評価ベンチマーク」の重要性や、現実世界で利用する上で避けられない「課題」にも触れています。特に、悪意のある攻撃からエージェントを守るセキュリティ問題や、個人情報の扱いに関するプライバシー問題、そしてAIが学習データから偏見を学んでしまう可能性といった倫理的な懸念が挙げられており、これらの課題解決に向けた研究も進んでいます。
応用例としては、科学研究における新しい発見の支援、医療現場での診断サポートや仮想的な患者シミュレーション、さらには経済や社会における人間の行動をモデル化してシミュレーションするなど、幅広い分野での活用が期待されています。
このように、LLMエージェントの研究は多岐にわたっており、その構築技術から複数での連携、自律的な賢さの向上、そして実用化に向けた課題解決まで、活発に研究が進められている注目の分野です。このサーベイ資料を読むことで、LLMエージェントの全体像と最新の研究動向を掴むことができるでしょう。
引用元: https://speakerdeck.com/shunk031/large-language-model-agent-a-survey-on-methodology-applications-and-challenges
CodeAgents + Structure: A Better Way to Execute ActionsAI（人工知能）が私たちに代わってタスクをこなす「AI Agent」の開発が進んでいます。これらのAgentが「行動」を起こす方法には、いくつかの進化がありました。
最初は「JSON Agent」という、事前に決められたツール（APIのようなもの）を呼び出すために、決められた形式（JSON）で指示を出す方法が主流でした。これは信頼性は高いのですが、できることが限られていたり、複数のツールを組み合わせて複雑な処理をするのが苦手でした。
次に登場したのが「Code Agent」です。これは、Agent自身がPythonなどのコードを書いて、そのコードの中でツールを呼び出す方法です。これにより、ループや条件分岐など、プログラムの柔軟性を活かして複雑なタスクをこなせるようになりました。例えば、複数の場所の天気情報を取得して平均を計算するなど、より賢いツールの使い方や、状況に応じた柔軟な対応が可能になりました。
しかし、Code Agentには問題がありました。LLM（大規模言語モデル）が出力するテキストからコード部分を正確に読み取る（パースする）のが難しく、形式が少し崩れただけでコードが実行できず、Agentがタスクを完了できなくなるエラーが頻繁に発生したのです。ベンチマークテストでも、最初のステップでパースエラーが起きると、成功率が大きく下がることが確認されました。
そこで、この記事では「Structured CodeAgent」という新しいアプローチが提案されています。これは、Code Agentの「コードを書く柔軟性」と、JSON Agentの「決められた形式（構造）で出力する信頼性」を組み合わせたものです。具体的には、LLMに「思考（thoughts）」と「コード（code）」を構造化されたJSON形式で強制的に出力させます。
{ "thoughts": "タスクをどう進めるか考える内容", "code": "実際に実行するPythonコード"}このようにすることで、Agentは行動を起こす前に「思考」を整理することが促され、さらに、コード部分がJSON内の明確なフィールドとして提供されるため、パースエラーが劇的に減り、コードの実行が信頼できるようになります。
このStructured CodeAgentを様々なテストで試したところ、特に高性能なLLMを使う場合、従来のCode Agentよりも2〜7%性能が向上することがわかりました。これは、パースエラーの減少と、思考プロセスが明示されることによる計画性の向上が主な理由と考えられます。
ただし、注意点もあります。JSON形式の出力や、それに加えてコードを書くという作業は、LLMにとってある種の「負担（Structure Tax）」になることがあります。特に小さなモデルでは、この負担が大きすぎて、かえって性能が落ちてしまうケースも見られました。
したがって、Structured CodeAgentは、高性能なLLMを使って、複雑なタスクをより信頼性高く実行したい場合に非常に有効なアプローチと言えます。簡単なタスクや、小規模なモデルを使う場合は、従来のCode AgentやJSON Agentの方が適しているかもしれません。
この記事は、AI Agentの設計において、「Agentが何をできるか」だけでなく、「Agentがどう考えるべきか」という視点が重要になっていることを示唆しており、今後のAgent開発のヒントになる研究です。
引用元: https://huggingface.co/blog/structured-codeagent
Large Language Models can run tools in your terminal with LLM 0.26OSSで開発されているLLM（大規模言語モデル）を扱うツール「LLM」の最新バージョン 0.26がリリースされました。今回のアップデートで一番大きな機能追加は、「ツールサポート」です。
「ツールサポート」とは、LLMに外部の機能（ツール）を使わせることで、LLM単体では難しかったタスクをこなせるようにする機能です。具体的には、Python関数として定義された様々な機能をツールとしてLLMに提供し、LLMが質問や指示に応じて最適なツールを選んで実行します。例えば、正確な計算をツールに任せたり、外部のデータベースから最新情報を取得したり、Web検索を実行したりといったことが可能になります。
この機能は、OpenAI、Anthropic、Google Geminiといった主要なLLMはもちろん、ローカルで動かせるOllamaのモデルなど、多くのLLMで利用できます。
使い方は簡単で、LLMのコマンドラインツール（CLI）を使う場合は、--tool オプションや、一時的にPython関数を渡せる--functions オプションを使います。また、PythonライブラリとしてLLMを利用している場合は、新しく追加された model.chain() メソッドを通してツール機能を活用できます。
今回のアップデートで、例えばLLMが苦手な数学計算も、計算ツールを使うことで正確に行えるようになりました。また、外部のデータベースに問い合わせるツールを使えば、最新のデータに基づいた回答を生成することも可能です。これは、LLMの能力を外部機能と連携させることで、大きく拡張できることを示しています。
このツールを使った一連の処理は、「エージェント」と呼ばれるAIの応用概念にも繋がる重要な技術です。LLMが自律的にツールを判断・実行し、複雑なタスクを達成する道が開かれます。
今後のLLMツール開発では、ツールを簡単に作る・共有する仕組みの強化や、AIと外部連携の新しい標準規格への対応なども進められる予定です。
今回のLLM 0.26のツールサポート機能は、LLMをより実用的でパワフルなものにするための大きな一歩と言えます。AIを活用したアプリケーション開発に興味のある新人エンジニアの皆さんにとって、ぜひチェックしておきたいアップデート内容です。
引用元: https://simonwillison.net/2025/May/27/llm-tools/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Build AI agents with the Mistral Agents API Mistral AI
Mistral AIが新しい「Agents API」を発表しました。これは、AIをもっと便利に、そして自分で考えて行動できる「エージェント」として使えるようにするためのものです。
従来のAIは、文章を作るのは得意でしたが、実際に何か行動したり、過去の会話の内容を覚えて続けて話したりするのが苦手でした。新しいAgents APIは、この課題を解決するために作られました。
Agents APIの主な特徴は以下の3つです。
組み込みコネクタ: AIエージェントがコードを実行したり、ウェブで情報を検索したり、画像を生成したり、独自のツール（MCPツール）を使ったりできるようになります。例えば、コード実行コネクタを使えば、AIが計算やデータ分析をしたりできます。ウェブ検索を使えば、最新の情報に基づいて応答できます。Document Libraryを使えば、アップロードしたドキュメントの内容を理解して応答（RAG）することも可能です。 永続的なメモリ: これまでの会話の内容をしっかり覚えています。これにより、スムーズで自然なやり取りが続き、文脈に沿った応答ができます。会話の途中から再開したり、話を分岐させたりもできます。 エージェントのオーケストレーション: 複数のAIエージェントを連携させて、複雑なタスクをこなすことができます。例えば、情報収集が得意なエージェントと、分析が得意なエージェントを連携させ、タスクを分担させて解決にあたらせるといったことが可能です。タスクを別々のエージェントに引き渡す「ハンドオフ」機能も備わっています。このAgents APIは、Mistralの既存のChat Completion APIとは異なり、AIエージェントを作るための専用のフレームワークです。これを使うことで、企業はAIをより実用的で効果的な方法で活用できるようになります。
この記事では、このAPIを使って作られたAIエージェントの具体例として、コードを書くのを手伝ってくれるアシスタントや、仕事のタスク管理をするアシスタント、金融分析をしてくれるアシスタントなどが紹介されています。（具体的な使い方については、Mistral AIが提供するcookbookなどで確認できます。）
この新しいAPIは、AIエージェント開発を進める上で非常に役立つ基盤となりそうです。興味を持った方は、ドキュメントを見て試してみてはいかがでしょうか。
引用元: https://mistral.ai/news/agents-api
DifyワークフローでDeepResearchを実現するこの記事は、AIを活用してより深く包括的な調査を自動で行う「DeepResearch」と、それを実現するためのツール「Dify」について、新人エンジニアにも分かりやすく解説しています。
まず、「DeepResearch」とは、単にキーワードで検索するだけでなく、AIが検索結果を基に次に調べるべき情報を考え、段階的に調査を深めていく仕組みです。これにより、人間が何時間もかけて手動で行うような、インターネット上の様々な情報源から関連データを集めて分析・統合する複雑な調査タスクを、AIが短時間で効率的に自動化できるようになります。OpenAIがChatGPTに統合した機能としても注目を集めています。
次に紹介されている「Dify」は、プログラミングのコードを書かずに、画面上でブロックを組み合わせて生成AIを使ったアプリケーションやワークフロー（AIに一連の作業を行わせる手順）を作成できる便利なプラットフォームです。直感的な操作（GUI）で、ChatGPTやClaudeなど、様々な大規模言語モデル（LLM）を組み合わせてAIアプリを開発できます。
この記事では、Difyの「ワークフロー」機能を使ってDeepResearchを実現する方法が説明されています。DifyにはDeepResearchのテンプレートが用意されており、これを利用することで簡単に始めることができます。このワークフローの核心となるのは、「イテレーションブロック」という繰り返し処理を行う部分です。ユーザーが調べたいテーマを入力すると、AI（LLMノード）がそのテーマを出発点として、これまでに得られた情報から「次に何を調べたらもっと詳しくなるか？」という新たな検索トピックを生成します。そして、そのトピックで再度検索・分析を自動で繰り返します。
この繰り返し（イテレーション）は、ユーザーがあらかじめ指定した回数を行うか、AIが「もう十分な情報が集まった」と判断するまで続きます。このように、AIが自律的に次の調査項目を判断し、自動で深掘りしてくれることで、手動では難しい多角的で深いリサーチが可能になります。
実際にこのワークフローをDifyで動かしてみたところ、単なる概要に留まらない、関連情報を含んだ包括的な調査結果が得られたとのことです。また、AIがどのように考えて次のトピックを生成したかという思考過程も確認できるようです。
結論として、Difyのワークフロー機能を使えば、AIが連続的に検索・分析を行い、調査の深さを自動で調整するDeepResearchを実現できることが示されています。Bedrockなどのクラウドサービスとも簡単に連携でき、柔軟なAIモデルの選択肢があるDifyは、調査業務の効率化を目指すエンジニアにとって強力なツールとなりそうです。
引用元: https://acro-engineer.hatenablog.com/entry/2025/05/26/120000
特化型大規模言語モデル『PLaMo翻訳』を公開しました - Preferred Networks Research & DevelopmentPreferred Networks（PFN）とPreferred Elements（PFE）が、国のプロジェクト（GENIAC）の一環で、高性能かつ軽量な大規模言語モデル（LLM）の開発を進めています。その中で今回、翻訳に特化したLLM『PLaMo翻訳』を開発し、誰でも利用できるデモページとともに公開しました。
翻訳技術はルールベース、統計的、そして現在のニューラル機械翻訳（NMT）と進化してきました。NMTは高性能ですが、学習には対訳データが大量に必要だったり、長文や文脈を理解した自然な翻訳が難しかったりする課題がありました。
『PLaMo翻訳』は、従来のNMTとは異なり、「LLMベース翻訳」という新しいアプローチを採用しています。まず、Web上の大量のテキストデータを使って大規模言語モデル（PLaMo）を事前学習し、その後、翻訳タスク向けに追加学習（ファインチューニング）しています。これにより、対訳データに過度に依存することなく、文章全体の流れや文脈、そして日本語特有の表現などをより深く理解できるようになりました。
PLaMo翻訳の大きな強みはいくつかあります。まず、Web上の多様な文章で学習しているため、論文のような堅い文章から物語のような柔らかい文章まで、原文の文脈や文体に合わせた自然で読みやすい翻訳が可能です。長い文章でも内容の一貫性を保てます。また、国産モデルであるPLaMoが日本語を非常に多く学習しているため、手元でも動かせる規模のモデルながら、高い日本語⇔英語の翻訳性能を実現しています。特に、一般的な対訳データには少ない慣用句なども適切に翻訳できる例が紹介されています（例：「家計は火の車だ」を「Our household finances are in dire straits」と適切に翻訳）。
このPLaMo翻訳はPLaMo Community Licenseのもと公開されており、デモページでその性能を試すことができます。PFNは、このモデルは高い性能を持ち商用利用も可能だと考えており、関心のある企業からの相談も受け付けています。
PFN/PFEでは、今後もLLM開発を続け、翻訳性能のさらなる向上を目指していくとのことです。
引用元: https://tech.preferred.jp/ja/blog/plamo-translate/
庭に住み着いてる猫のためにいい将来を用意しようとしていたが、紆余曲折あって結局うちの猫になった話「律儀でワロタ」庭に住み着いた野良猫「ごんた」の良い飼い主を見つけようとした漫画家さん。しかし、律儀で愛らしいごんたの姿に心奪われ、結局自分が家族として迎え入れることになりました。野良猫だったごんたが家猫になるまでの温かいエピソードと、ごんたのユニークな魅力に癒やされると評判です。
引用元: https://togetter.com/li/2555980
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Infinite tool use
この記事では、これからの大規模言語モデル（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
エディタ型からCLI型・自律型へと多様化するコーディングエージェント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への入力や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が単なる情報検索だけでなく、言葉遊びやニュアンスを理解して気の利いた返しができる可能性を示唆しており、AIとの対話の面白さを感じさせる一例として話題です。
引用元: https://anond.hatelabo.jp/20250526161912
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Claude Code Actionのプロンプト設計が、AIエージェント開発にかなり参考になる件
最近、「Devin」のようなコードを自動で書いたり修正したりするAIエージェントが注目されています。Anthropic社が提供する「Claude Code」もその一つで、なんとその仕組みのコードがGitHub上で公開されています。この記事では、この「Claude Code」がどのようにGitHub上で動き、特にAIへの「指示の出し方（プロンプト設計）」がどのように工夫されているかを、新人エンジニアの方にも分かりやすく解説しています。
Claude Code GitHub Actionsとは？Claude Codeは、GitHub Actionsという開発作業を自動化する仕組みの上で動作するAIエージェントです。プルリクエスト（PR）やIssue（課題）で「@claude」とメンションするだけで、AIがコードの分析、PRの作成、機能の実装、バグ修正などを自動で行ってくれます。
このAIエージェントの大きなメリットは以下の点です。
カスタマイズ性: AIの動きや使うツールを、GitHubのワークフローという設定ファイルで細かく調整できます。 透明性: AIが行ったすべての作業内容や指示が、GitHubのログに記録されるため、後から確認しやすいです。 連携性: 既存の自動テスト（CI/CD）の仕組みにも組み込むことができ、開発プロセスをスムーズにできます。AIを動かす「プロンプト設計」の秘密AIエージェントが賢く動くためには、AIに適切な「指示書」、つまり「プロンプト」を与えることがとても重要です。Claude Codeでは、このプロンプトが非常に丁寧に設計されており、AIエージェント開発の良いお手本となります。
プロンプトは大きく分けて以下の要素で構成されています。
AIの役割定義: まず最初に「あなたはGitHubの課題やPRを助けるAIアシスタントです」のように、AIが何をするものなのかを明確に伝えます。 現在の状況（コンテキスト）の共有: Issueのタイトル、内容、これまでのコメント、変更されたファイルなど、AIが作業を進める上で必要な情報をすべて伝えます。これにより、AIは状況を正確に理解できます。 具体的な作業手順の指示: AIがタスクをどのように進めるべきか、具体的なステップを細かく指示します。例えば、「ToDoリストを作成し、進捗を更新すること」「状況を分析し、ユーザーの要望を理解すること」「要望に応じてコードを修正するか、レビューコメントをすること」といった手順が示されます。 AIの能力と限界の明確化: AIができること（コードレビュー、単純な変更実装、PR作成）とできないこと（PRの承認、リポジトリ外のコマンド実行など）がはっきりと定義されています。これにより、AIが予期せぬ動作をしたり、危険な行動をとったりするのを防ぎ、安全に運用できるよう工夫されています。特に注目すべきは、AIが実際に作業を始める前に、与えられた情報をもとに「状況を分析し、どんな作業が必要か、どう進めるか」を検討する「分析フェーズ」が設けられている点です。これにより、AIはすぐに作業にとりかかるのではなく、一度立ち止まって計画を立てるため、より適切で安全な行動が期待できます。
まとめClaude Codeのプロンプト設計は、AIがコードを自動で処理するだけでなく、開発プロセスに安全かつ効率的に組み込むための多くのヒントを与えてくれます。特に、複雑な状況をAIに正確に伝え、AIの行動を細かく制御し、さらに「できること・できないこと」を明確にすることで、開発者にとって使いやすく、信頼できるAIエージェントを構築する道筋を示していると言えるでしょう。
引用元: https://zenn.dev/gotalab/articles/claudecode_9626d853742423
グーグルの「Gemini」がさらに進化、押さえておきたい8つのポイントGoogleは年次開発者会議「Google I/O 2025」で、AIアシスタント「Gemini」の大きな進化を発表しました。新人エンジニアの皆さんが押さえておきたい主要なポイントをまとめます。
まず、Geminiには二つの新しい有料プラン「Google AI Pro」と「Google AI Ultra」が登場しました。「AI Pro」（月額20ドル）は、既存の「Gemini Advanced」の名称変更で、チャットAI機能に加え、テキストからノートを作成する「NotebookLM」やAI動画エディター「Flow」などが追加され、より多くの機能が使えるようになります。特に、日本を含む一部地域の大学生は1年間無料で利用可能です。「AI Ultra」（月額250ドル）は、さらに高性能なモデルや実験的なAI機能への早期アクセスを提供し、中でも注目は「Agent Mode」です。これはユーザーの代わりにウェブを閲覧したり、調査したり、Googleアプリと連携して複雑なタスクを自動で処理してくれる、まるでAI秘書のような機能です。
次に、音声対話機能「Gemini Live」が大幅に強化されました。これまでの音声対話に加え、AndroidとiOSデバイスでスマートフォンのカメラ映像や画面をGeminiに共有し、それについて質問できるようになりました。例えば、目の前の物体をGeminiに説明してもらったり、デバイス上の画面内容を分析してもらったりできます。さらに、今後はGoogleマップやカレンダー、タスク管理アプリのKeepなどとも連携し、AIにカレンダーの予定作成や道案内を依頼できるようになる予定です。
また、画像生成モデル「Imagen」は「Imagen 4」に進化し、よりリアルで高品質な画像を生成できるようになりました。テキストの表現力も向上し、Geminiアプリを通じて誰でも試すことができます。動画生成ツール「Veo」も「Veo 3」にアップグレードされ、動画に登場するキャラクターの対話や背景音、効果音といった自然なオーディオを自動で生成する機能が加わりました。テキストで指示するだけで、動画にぴったりのサウンドを付けられるようになり、表現の幅が広がります。
これらの進化により、Geminiは単なるチャットAIを超え、より多機能で日常生活や仕事に深く統合されるAIアシスタントへと変貌を遂げています。特にAgent Modeのような自律的なタスク処理機能は、今後のAI活用において重要なトレンドとなるでしょう。
引用元: https://japan.zdnet.com/article/35233246/
Peer Programming with LLMs, For Senior+ Engineersこの記事は、LLM（大規模言語モデル）をプログラミング作業に効果的に活用する方法について、シニアエンジニアの実践的な視点からまとめられたものです。新人エンジニアの皆さんにも、将来役立つヒントや、今すぐにでも試せるAI活用術が含まれています。
LLMはコードの作成やデバッグを助ける強力なアシスタントですが、その一方で、使い方を間違えると時間を無駄にしてしまうこともあります。しかし、経験豊富なエンジニアは、LLMをまるで「プログラミングの相棒」のように活用し、作業の効率を大きく向上させています。
具体的には、以下の実践的な使い方が紹介されています。
「セカンドオピニオン」として使う:LLMを自分のアイデアや書いたコードのレビューに活用します。例えば、「このコードはもっと改善できるか？」「この設計で問題ないか？」といった質問を投げかけ、LLMから別の視点や提案を得ることで、より良い解決策を見つける手助けになります。これは、一人で悩む時間を減らし、多角的な視点を得るのに役立ちます。
「使い捨てデバッグスクリプト」を作る:プログラムのバグを特定するために、一時的に使うデバッグ用の小さなスクリプトをLLMに作成してもらう方法です。複雑な問題の原因究明に役立つ、特定のログを出力するスクリプトや、特定の条件下で動作を確認するコードなどを素早く生成させることで、デバッグ時間を短縮できます。
コード生成のワークフローに組み込む:新しい機能やプロトタイプを開発する際、LLMを計画段階から活用します。まずは、作りたいものの「仕様のアイデア出し」をLLMと行い、次に具体的な「開発計画」をLLMと一緒に立てます。その計画に基づいて「コードを生成」してもらい、これを繰り返すことで、効率的に開発を進めます。ただし、LLM任せにせず、人が主導して方向性を決めることが重要です。
プロンプトを文書化する:LLMに質問や指示（プロンプト）を出す際、うまくいったプロンプトは記録しておくことが推奨されています。どのプロンプトが期待通りの結果をもたらしたかを覚えておくことで、次回以降、より効率的にLLMを活用できるようになります。これは、自分がLLMを使いこなすための「ノウハウ」を蓄積する作業とも言えます。
LLMの特性を理解する:LLMは非常に賢く見えますが、万能ではありません。完璧な答えを常に返してくれるわけではなく、間違った情報を出力することもあります。LLMはあくまで便利な「道具」であり、その限界を理解した上で、賢く使いこなす視点が重要です。例えば、生成されたコードや情報は必ず自分で確認し、適切に修正する意識が大切です。
まとめると、LLMは開発者の強力な味方になりますが、その力を最大限に引き出すには、適切な使い方と、その限界を理解することが不可欠です。困ったときは、まずLLMに相談し、それでも解決しなければ経験豊富な先輩や同僚に助けを求める、というアプローチも有効です。ぜひこれらのヒントを参考に、日々の開発作業にLLMを取り入れてみてください。
引用元: https://pmbanugo.me/blog/peer-programming-with-llms
猫影ポーズをする人のイラスト「いらすとや」に、猫影ポーズを楽しむ可愛らしいイラストが新しく追加されました！手で猫の影絵を作って遊んでいる女の子のイラストで、見ているだけで心が和みます。資料作成などでちょっとしたイラストが欲しい時に、無料で使える「いらすとや」は私たちエンジニアにとっても心強い味方。息抜きやアイデア出しにも、ぜひ活用してみてくださいね。
引用元: https://www.irasutoya.com/2025/05/blog-post_25.html
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
- Visa fler
