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

ストックマーク株式会社が、日本語のドキュメント理解に特化した新しい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

この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

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を入れると、機械の中で小さなクリーンルームのような環境を作り、ホコリや気泡を抑えながら画面クリーニングとフィルム貼りを約2分で完了します。手作業の煩わしさを解消する、ユニークなテクノロジーの活用事例として注目されています。

引用元: https://togetter.com/li/2559302

（株式会社ずんだもんは架空の登場組織です）

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

大規模言語モデル（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

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

（株式会社ずんだもんは架空の登場組織です）

この記事は、生成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

この論文は、金融分野で活用が広がる大規模言語モデル（LLM）の「解釈可能性」、つまり「なぜAIがその結果を出したのか」を理解することの重要性とそのための技術について論じています。

LLMは現在、金融業界において、レポート作成、顧客対応チャットボット、市場センチメントの分析、規制遵守のチェック、投資アドバイス、情報の検索や要約など、様々なタスクで優れた能力を発揮しています。しかし、LLMは非常に複雑な構造を持つため、内部の動作原理が分かりにくい「ブラックボックス」状態になりやすいという大きな課題があります。

金融業界は、その性質上、極めて厳格な規制があり、システムに対する高いレベルの透明性、公平性、そして何か問題が起きた際に責任を明確にするための説明責任が不可欠です。「AIがなぜその判断を下したのか」を説明できなければ、特に人の財産や重要な判断に関わる場面で、安心して利用することが難しいのです。

この論文では、この課題を解決するために、「機構的解釈可能性（Mechanistic Interpretability）」という比較的新しい技術アプローチを、金融分野で初めて応用した事例として提示しています。機構的解釈可能性とは、LLMの内部構造や動作を文字通り「分解して逆さまに調べる」ことで、モデルがどのように情報を処理し、特定の振る舞いを生み出しているのかを最も分かりやすく理解しようとする手法です。モデルの内部にある情報の流れや処理のまとまり（「回路」と呼ばれることもあります）を詳細に分析することで、「なぜ」特定の予測や応答が生まれたのかを深く理解できます。そして、単に理解するだけでなく、モデルの望ましくない振る舞いを特定し、修正するための手助けにもなります。

論文では、この機構的解釈可能性の理論的な側面を解説しつつ、トレーディング戦略における意思決定プロセスの理解、市場センチメント分析での根拠特定、さらにはAIが持つ可能性のある偏り（バイアス）や事実に基づかない情報（ハルシネーション）の検出といった、金融分野における具体的な様々な応用例とその実験結果を示しています。

機構的解釈可能性はまだ開発途上の技術ですが、LLMの金融分野への浸透が進むにつれて、その重要性はますます高まると予測されています。このような高度な解釈可能性の技術は、AIシステムが常に倫理的であり、透明性を保ち、厳格な金融規制に適合し続けるために不可欠なツールとなるでしょう。論文の著者らは、特に金融規制やコンプライアンスの観点から、これらの技術が現在のニーズだけでなく、将来の世界の金融規制当局からの期待にも応えうる可能性を強調しています。

この研究は、LLMを金融のような信頼性が極めて重要な分野で、安全かつ責任を持って利用するための技術的な基盤を築く一歩と言え、AIの信頼性向上に関心のあるエンジニアにとって注目すべき内容です。

引用元: https://arxiv.org/abs/2505.24650

この記事は、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才の証明」の配信を開始しました。この記事は、その新曲が主要な音楽配信サービスで聴けるようになったことを伝えるニュースです。プログラミングやAI関連でも見かける「ずんだもん」が楽曲に参加しているのは面白いですね。新しい技術やキャラクターが様々な分野で活躍する例として、ちょっと息抜きに聴いてみるのも良いかもしれません。

引用元: https://magazine.tunecore.co.jp/newrelease/513439/

（株式会社ずんだもんは架空の登場組織です）

このニュースは、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

この記事は、LLM（大規模言語モデル）を開発する上で、ファインチューニングがどのような場合に役立つのか、その具体的なメリットと始め方について、開発者向けに解説しています。

AIモデルの能力を引き出すためにプロンプトを工夫することは重要ですが、プロンプトだけでは限界がある場合があります。例えば、出力形式（JSONなど）が安定しない、プロンプトが長くなりすぎてコストや速度が悪化する、モデルに特定の細かいルールや振る舞いを教えたい、といった問題です。このような、プロンプトでは解決しきれない具体的な課題に対して、ファインチューニングは非常に有効な手段となります。

ファインチューニングを行うことには、主に以下のようなメリットがあります。

ただし、知識の追加を目的とする場合は、ファインチューニングは最適な方法ではありません。最新情報や特定の知識をモデルに参照させたい場合は、RAG（外部情報参照）や、プロンプトに直接コンテキストとして情報を含める方法の方が適しています。

ファインチューニングを始める際は、まず「何を解決したいのか」という具体的な目標を明確にすることが大切です。その目標に合わせて、どのベースモデルを使うかを選びます。少量でも良いので学習データを用意し、実際に学習させて結果を評価し、改善を繰り返していくのが基本的な流れです。

このように、ファインチューニングは、プロンプトだけでは実現が難しいAIモデルのカスタム化や性能改善のための強力な手法です。特定の問題に直面しているエンジニアにとって、試す価値のある技術と言えるでしょう。

引用元: https://getkiln.ai/blog/why_fine_tune_LLM_models_and_how_to_get_started

DeepSeekのような大規模言語モデル（LLM）が、なぜサービスとして大規模に提供されると安価で高速なのに、自分のパソコンなどローカル環境で動かすと遅く高価になるのか、という疑問について技術的な観点から解説しています。

その主な理由は、AI推論を行う際の「スループット」（単位時間あたりに処理できる量）と「レイテンシ」（応答速度、待ち時間）の間に存在するトレードオフにあります。このトレードオフは、推論処理の際に「バッチサイズ」（複数のユーザーからのリクエストをまとめて一度に処理する数）をどう設定するかによって生じます。

GPUは、多数の計算をまとめて大きなひとつの行列計算（GEMM）として行うのが非常に得意です。これに対し、小さな行列計算を何度も繰り返すのは苦手です。バッチ推論では、複数のユーザーからのリクエストをまとめて大きなバッチとしてGPUに投入します。これにより、個々のリクエストをバラバラに処理するよりも、GPUを効率的に使い、全体としての処理能力（スループット）を大幅に向上させることができます。

しかし、このバッチ処理には待ち時間が伴います。例えば、「バッチサイズ128」で処理すると決めた場合、リクエストは128件分集まるまで待機キューで待つことになります。バッチサイズが大きいほど、GPUの利用効率は上がりスループットは向上しますが、個々のユーザーの応答が返ってくるまでの時間（レイテンシ）は長くなります。逆にバッチサイズが小さいとレイテンシは短くなりますが、GPUが非効率になりスループットは低下します。

特にDeepSeek-V3のような「Mixture-of-Experts (MoE)」と呼ばれるアーキテクチャを持つモデルや、層が多く大規模なモデルは、その構造上、GPUの効率的な利用のために大きなバッチサイズがほぼ必須となります。

そのため、DeepSeekのようなモデルは、多くのユーザーからの同時リクエストがある大規模なサービス環境では、大きなバッチサイズで効率的に実行できます。しかし、ローカル環境で一人のユーザーが使う場合、バッチサイズが非常に小さくなるため、GPUが非効率になり、結果として処理が遅く感じられるのです。

OpenAIやAnthropicのモデルが比較的応答が速いのは、アーキテクチャが異なるか、推論効率を高める特別な技術を使っているか、あるいはGPUを大量に投入して低レイテンシを実現している可能性があると推測されています。

このバッチ処理によるスループットとレイテンシのトレードオフは、LLMの運用コストや性能を理解する上で重要な考え方です。

引用元: https://www.seangoedecke.com/inference-batching-and-deepseek/

VTuberと声優が舞台で初めて生共演する朗読劇が6月に原宿で開催されます。「ずんだもん」の声優さんや、VTuberの春日部つくしさんらが出演。リアルタイムでキャラクターを動かす技術を使った「ハイブリッド演劇」として注目されています。新しいエンタメ技術に興味のある新人エンジニアさんは要チェックです。

引用元: https://hotakasugi-jp.com/2025/06/01/stage-news-zundamon-kasukabetsukushi/

VOICEVOX:春日部つむぎ

最近は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

この記事は、イオンネクストで技術戦略を担当されている筆者が、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と比較したところ、それぞれ違いが見られました。

PRレビューツールとしては、Copilot Code ReviewとClaude Code Action（レビュー用にプロンプト調整）を比較しました。

まとめとして、Claude Code Actionは他のツールと比較しても実用的な品質であり、プロンプトの調整やナレッジの蓄積でさらに精度が向上する可能性を述べています。エージェント型AIの導入コストにハードルを感じる企業は、まずはClaude Code ActionとVertex AI/Bedrockの組み合わせで試してみるのが良い選択肢となり得ると提案しています。ただし、Vertex AIは従量課金のため、コスト管理は必要です。

引用元: https://zenn.dev/aeonpeople/articles/1ec37f3ae91995

LLM（大規模言語モデル）は進化していますが、最新情報や固有の知識には弱点があります。この課題を解決する技術がRAG（検索拡張生成）です。RAGは、あらかじめ用意した資料（知識ベース）の中から、ユーザーの質問に関連する部分を検索し、その情報をLLMに与えることで、より適切で正確な回答を引き出します。

RAGアプリを開発する際、その便利さからセキュリティが後回しになりがちですが、いくつかの重要なリスクが存在します。この記事では、特にRAG特有のリスクと対策に焦点を当てて解説しています。

RAGアプリのセキュリティリスクはいくつかありますが、特に気をつけたいのは以下の点です。

これらのリスクのうち、特にRAGで重要な役割を果たすVector store（知識ベースをベクトル形式で保存・検索するデータベース）に関連するデータ汚染とデータ漏洩について詳しく解説されています。

Vector storeの「データ汚染」を防ぐには、知識ベースに入れるデータの信頼性を確認することが基本です。外部からデータを取り込む場合は、信頼できる情報源かを確認したり、データの種類でフィルタリングしたりといった対策が有効です。

Vector storeからの「データ漏洩」を防ぐには、先ほどの「認可制御」が鍵となります。マルチテナント環境では、ユーザーごとにアクセスできるデータを厳密に分ける必要があります。この認可制御の実装方法は、利用するVector storeのライブラリによって異なります。ライブラリによっては、マルチテナントに対応した機能が備わっているものや、データを区別するための情報を付けて検索時に絞り込む方法（metadata filtering）で対応できるものがあります。metadata filteringを使う際は、悪意のある入力を防ぐための対策（サニタイズなど）をしっかり行う必要があります。独自の認可制御を実装するとミスが発生しやすいため、可能な限りライブラリの機能を利用するか、専門家のレビューを受けることが推奨されます。

RAGアプリ開発では、その機能性だけでなく、データ汚染や情報漏洩といったセキュリティリスクを理解し、適切な対策を講じることが、安全なシステムを構築するために不可欠です。

引用元: https://blog.flatt.tech/entry/rag_security

NTTからサイバー攻撃セミナーの案内が来たものの、現場では「アライグマから光ファイバーケーブルを守る」という物理的な課題に取り組んでいるツイートが話題に。ITインフラはサイバー攻撃だけでなく、動物による物理的な被害対策も意外と重要であることをユーモラスに伝えています。過去にはセミやリスの対策もあり、システムの安定稼働には様々な視点が必要だと分かりますね。

引用元: https://togetter.com/li/2556533

VOICEVOX:ずんだもん

この資料は、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

AI（人工知能）が私たちに代わってタスクをこなす「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形式で強制的に出力させます。

このようにすることで、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

OSSで開発されている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/

（株式会社ずんだもんは架空の登場組織です）

Mistral AIが新しい「Agents API」を発表しました。これは、AIをもっと便利に、そして自分で考えて行動できる「エージェント」として使えるようにするためのものです。

従来のAIは、文章を作るのは得意でしたが、実際に何か行動したり、過去の会話の内容を覚えて続けて話したりするのが苦手でした。新しいAgents APIは、この課題を解決するために作られました。

Agents APIの主な特徴は以下の3つです。

このAgents APIは、Mistralの既存のChat Completion APIとは異なり、AIエージェントを作るための専用のフレームワークです。これを使うことで、企業はAIをより実用的で効果的な方法で活用できるようになります。

この記事では、このAPIを使って作られたAIエージェントの具体例として、コードを書くのを手伝ってくれるアシスタントや、仕事のタスク管理をするアシスタント、金融分析をしてくれるアシスタントなどが紹介されています。（具体的な使い方については、Mistral AIが提供するcookbookなどで確認できます。）

この新しいAPIは、AIエージェント開発を進める上で非常に役立つ基盤となりそうです。興味を持った方は、ドキュメントを見て試してみてはいかがでしょうか。

引用元: https://mistral.ai/news/agents-api

この記事は、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

Preferred Networks（PFN）とPreferred Elements（PFE）が、国のプロジェクト（GENIAC）の一環で、高性能かつ軽量な大規模言語モデル（LLM）の開発を進めています。その中で今回、翻訳に特化したLLM『PLaMo翻訳』を開発し、誰でも利用できるデモページとともに公開しました。

翻訳技術はルールベース、統計的、そして現在のニューラル機械翻訳（NMT）と進化してきました。NMTは高性能ですが、学習には対訳データが大量に必要だったり、長文や文脈を理解した自然な翻訳が難しかったりする課題がありました。

『PLaMo翻訳』は、従来のNMTとは異なり、「LLMベース翻訳」という新しいアプローチを採用しています。まず、Web上の大量のテキストデータを使って大規模言語モデル（PLaMo）を事前学習し、その後、翻訳タスク向けに追加学習（ファインチューニング）しています。これにより、対訳データに過度に依存することなく、文章全体の流れや文脈、そして日本語特有の表現などをより深く理解できるようになりました。

PLaMo翻訳の大きな強みはいくつかあります。

このPLaMo翻訳はPLaMo Community Licenseのもと公開されており、デモページでその性能を試すことができます。PFNは、このモデルは高い性能を持ち商用利用も可能だと考えており、関心のある企業からの相談も受け付けています。

PFN/PFEでは、今後もLLM開発を続け、翻訳性能のさらなる向上を目指していくとのことです。

引用元: https://tech.preferred.jp/ja/blog/plamo-translate/

庭に住み着いた野良猫「ごんた」の良い飼い主を見つけようとした漫画家さん。しかし、律儀で愛らしいごんたの姿に心奪われ、結局自分が家族として迎え入れることになりました。野良猫だったごんたが家猫になるまでの温かいエピソードと、ごんたのユニークな魅力に癒やされると評判です。

引用元: https://togetter.com/li/2555980

（株式会社ずんだもんは架空の登場組織です）

この記事では、これからの大規模言語モデル（LLM）は、自分で文章などを直接生成するのではなく、「ツールを呼び出すこと」と「そのツールへの指示（引数）」だけを出力することに専念すべきだ、という革新的な考え方が提案されています。

なぜこのように考えるのでしょうか？それは、LLMと外部ツールがそれぞれの得意なことに特化し、協力することで、より効率的で強力なシステムを構築できるからです。ツールは、特定のタスクの状態や目標、過去の作業履歴といった「具体的な情報」や「操作」を保持し実行します。一方、LLMは、次にどのツールをどう使うか判断するために必要な「直近の情報」や「全体的な状況」だけを持つようにします。これにより、LLM自身の記憶や処理の負担を減らし、より効率的で専門的な処理を外部のプログラム（ツール）に任せることができます。

現在の多くのLLMは、指示に対してテキストを一気に生成します。この方法にはいくつかの課題があります。例えば、長い文章を作成する際に、途中で間違いを訂正したり、全体の構成を大きく変更したりするのが難しいです。人間のように、大まかなアイデアから書き始め、細部を詰め、後から自由に行き来して修正するような柔軟な作業（マルチ解像度生成）が苦手なのです。また、生成されるテキストが長くなると、LLMが保持する情報量が増えすぎてしまい、処理が難しくなる問題もあります。

ここで「ツールを使う」という考え方が力を発揮します。

LLMが文章を直接生成する代わりに、まるで人間が使うような「テキストエディタ」というツールを操作するコマンドだけを出力することを想像してください。LLMは「この段落を削除」「ここにこの文章を追加」「この部分を修正」といった指示をツールに送ります。ツールは指示通りに文章を編集し、その結果をLLMに返します。これにより、LLMは文章を途中から自由に編集したり、構成を大きく変えたりといった、人間のような試行錯誤を伴う柔軟な作業が可能になります。間違いもツール上で修正すれば、LLM自身の記憶を混乱させることもありません。

この考え方は、文章生成だけでなく、様々なタスクに応用できます。例えば、3Dモデルを作成する場合、LLMは3Dモデリング用のコードを生成・実行するツールを操作します。長い動画を理解する場合も、動画の特定部分を視聴したり、重要な情報をメモしたりするツールを使うことで、効率的に処理を進められます。

ツールを使うことで、LLMは複雑なタスクに取り組む際に、ツール上でどのような思考や操作を行ったかをより明確に表現する必要があります。これは、LLMの出力がより分かりやすくなり、意図しない挙動を防ぐといった安全性にもつながる可能性があります。

まとめると、「無限ツール使用」という新しい設計思想は、現在のLLMの限界を克服し、より複雑で大規模なタスクに柔軟に対応できる、効率的で安全なAIアシスタントを実現するための鍵となる可能性を秘めています。これを実現するには、コンテキストサイズに関わらず効率的に推論できるアーキテクチャなどが重要になると考えられています。

引用元: https://snimu.github.io/2025/05/23/infinite-tool-use.html

AIコーディングエージェントは進化し、今ではその「自律性」「動作環境」「ユーザーとの対話方法」が重要視されるようになりました。この記事では、現在のコーディングエージェントをエディタ型、CLI型、自律型の3つのタイプに分類し、それぞれの特徴やおすすめ製品、使い分けについて解説しています。

エディタ型（例: Cursor, GitHub Copilot）は、エディタ内で動作し、まるで自動運転レベル2のように、開発者が常に監視・介入しながらコード編集を行います。安全性を重視し、全ての変更を確認しながら進めたい場合に適しています。入門者向けの学習リソースが豊富で、最初に試すのに適したタイプです。Cursorやコストを抑えたいならCopilot Chat、仕組みを理解したいならRoo Codeが紹介されています。

CLI型（例: Claude Code, Codex CLI）は、ターミナル（コマンドライン）上で動作します。自動運転レベル3のように、エージェントが主体となって開発を進め、重要な判断時に開発者に確認を求めます。効率性向上を重視し、柔軟な操作や外部連携がしやすいのが特徴です。CLI型はエディタから独立しているため、エディタ型が合わなかった開発者にもおすすめです。Claude Codeは性能が高いですがコストがかかる可能性があり、Amazon Q Developer CLIは無料プランがあり低コストで試せます。仕組みを知りたい場合は、GitHub上で公開されているCodex CLIが参考になります。

自律型（例: Devin, OpenHands）は、独立した環境で、目標設定と結果確認のみでタスク完了を目指すタイプです。自動運転レベル4のように、開発者の介入を最小限にし生産性最大化を目指します。まだ実験的な段階ですが、タスク成功率が高ければ生産性を大きく向上させられます。ただし、現状はコーディング知識なしに使えるレベルではなく、適切な指示やコンテキスト準備が必要です。新技術に関心があり、検証したいアーキテクト向けと言えます。製品としては先行するDevinや、無料で利用できるJulesが挙げられています。自律型のOSSとしては、GitHubでOpenHandsが公開されています。

どのタイプにも優劣はなく、開発者の好みやタスクの内容によって適したものが異なります。新人エンジニアの方は、まず学習リソースが多いエディタ型から試してみるのがおすすめです。そして、AIコーディングエージェントの動向を追っていくことが、今後の開発に役立つでしょう。

引用元: https://blog.lai.so/agent/

近年、LLM（大規模言語モデル）を使ったアプリケーション開発が進む中で、セキュリティ対策に悩むエンジニアが増えています。その中で注目されている技術の一つが「LLMガードレール」です。これは、LLMへの入力やLLMからの出力を監視・制御する技術の総称で、例えるならWebアプリケーションにおけるWAFのような役割を果たします。

LLMガードレールには、入力に含まれる不適切な内容や悪意のある指示を検出・ブロックする「入力フィルタリング」、LLMが生成したテキストがポリシーに違反していないか、特定のトピックから逸脱していないかなどを検証・修正・ブロックする「出力内容の制御」といった機能があります。

検証によると、現代のLLMは一般的な有害コンテンツ（例えば爆弾の作り方）はフィルタリングしてくれますが、パン屋botの例のように、アプリケーション固有のルール（「提供商品リスト以外のパンを紹介しない」など）からの逸脱はLLM本体だけでは防ぎきれません。こういったドメイン固有の不適切な出力を抑えるのに、LLMガードレールによる出力制御が役立ちます。

また、プロンプトインジェクション（悪意のある指示でLLMの動作を操作する攻撃）に対して、入力ガードレールは有効な対策となり得ます。しかし、多様な攻撃手法が存在するため、ガードレールだけでは完全に防ぐことは非常に難しいのが現状です。「プロンプトインジェクションはされるものだ」と考え、LLMに不用意な機密情報を持たせないなどの対策と組み合わせることが重要です。

さらに、RAG（外部情報を参照してLLMの回答精度を向上させる技術）や、外部サービスと連携するLLMアプリケーションの場合、ガードレールはあくまで入力や出力の「テキスト内容」を検証するものです。RAGで参照する外部データベースが汚染された場合の対策や、外部連携における認可（特定の操作をしてよいか）の判断は、ガードレールだけでは困難です。これらの脅威に対しては、信頼できるデータソースのみを利用する、最小権限の原則を適用するといった根本的なセキュリティ対策が不可欠です。

結論として、LLMガードレールはLLMアプリケーションのセキュリティリスクを低減するための有用なツールですが、あくまで「緩和策」「セーフティネット」であると理解することが大切です。LLMガードレールを過信せず、アプリケーションの設計段階から基本的なセキュリティ対策（安全な設計、適切な権限管理、レートリミットなど）をしっかりと行い、その上で多層防御の一つとしてLLMガードレールを導入・活用していくことが、安全なLLMアプリケーション開発には欠かせません。

引用元: https://blog.flatt.tech/entry/llm_guardrail

AIに「綾波レイとブルーレイはどちらがきれいか？」という問いかけをしたところ、AIは「映像の美しさならブルーレイ、感情の奥行きなら綾波レイ」と回答しました。このユーモアと洞察力のある応答は、AIが単なる情報検索だけでなく、言葉遊びやニュアンスを理解して気の利いた返しができる可能性を示唆しており、AIとの対話の面白さを感じさせる一例として話題です。

引用元: https://anond.hatelabo.jp/20250526161912

（株式会社ずんだもんは架空の登場組織です）

最近、「Devin」のようなコードを自動で書いたり修正したりするAIエージェントが注目されています。Anthropic社が提供する「Claude Code」もその一つで、なんとその仕組みのコードがGitHub上で公開されています。この記事では、この「Claude Code」がどのようにGitHub上で動き、特にAIへの「指示の出し方（プロンプト設計）」がどのように工夫されているかを、新人エンジニアの方にも分かりやすく解説しています。

Claude Code GitHub Actionsとは？

このAIエージェントの大きなメリットは以下の点です。

AIを動かす「プロンプト設計」の秘密

プロンプトは大きく分けて以下の要素で構成されています。

特に注目すべきは、AIが実際に作業を始める前に、与えられた情報をもとに「状況を分析し、どんな作業が必要か、どう進めるか」を検討する「分析フェーズ」が設けられている点です。これにより、AIはすぐに作業にとりかかるのではなく、一度立ち止まって計画を立てるため、より適切で安全な行動が期待できます。

まとめ

引用元: https://zenn.dev/gotalab/articles/claudecode_9626d853742423

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/

この記事は、LLM（大規模言語モデル）をプログラミング作業に効果的に活用する方法について、シニアエンジニアの実践的な視点からまとめられたものです。新人エンジニアの皆さんにも、将来役立つヒントや、今すぐにでも試せるAI活用術が含まれています。

LLMはコードの作成やデバッグを助ける強力なアシスタントですが、その一方で、使い方を間違えると時間を無駄にしてしまうこともあります。しかし、経験豊富なエンジニアは、LLMをまるで「プログラミングの相棒」のように活用し、作業の効率を大きく向上させています。

具体的には、以下の実践的な使い方が紹介されています。

「セカンドオピニオン」として使う:

「使い捨てデバッグスクリプト」を作る:

コード生成のワークフローに組み込む:

プロンプトを文書化する:

LLMの特性を理解する:

まとめると、LLMは開発者の強力な味方になりますが、その力を最大限に引き出すには、適切な使い方と、その限界を理解することが不可欠です。困ったときは、まずLLMに相談し、それでも解決しなければ経験豊富な先輩や同僚に助けを求める、というアプローチも有効です。ぜひこれらのヒントを参考に、日々の開発作業にLLMを取り入れてみてください。

引用元: https://pmbanugo.me/blog/peer-programming-with-llms

「いらすとや」に、猫影ポーズを楽しむ可愛らしいイラストが新しく追加されました！手で猫の影絵を作って遊んでいる女の子のイラストで、見ているだけで心が和みます。資料作成などでちょっとしたイラストが欲しい時に、無料で使える「いらすとや」は私たちエンジニアにとっても心強い味方。息抜きやアイデア出しにも、ぜひ活用してみてくださいね。

引用元: https://www.irasutoya.com/2025/05/blog-post_25.html

（株式会社ずんだもんは架空の登場組織です）

Microsoft Build 2025では、「Building the open agentic web」（AIエージェントが活躍する開かれたウェブの世界を構築する）をテーマに、開発者向けの様々な新発表がありました。発表は主に「アプリとAIエージェント」「AIプラットフォーム」「データ」「インフラ」の4つの階層に分けて紹介されました。

特に注目すべきは、AI開発やエンジニアの働き方に関わる変化です。

まず、開発者にとって身近なGitHub CopilotのVS Code拡張機能がOSS化されました。これにより、コード補完やChat、Agent機能などを誰でも自由に改変・検証できるようになり、企業やコミュニティでの拡張やセキュリティ監査が容易になります。GitHubのIssueにCopilotを割り当てて、コード修正やPR作成を自動化するといった自律的な開発スタイルもサポートされます。これは、AIが単なるアシスタントから、HumanとAIが互いにタスクを割り当てる「共働者」へと進化していく流れを示すものです。

また、システムの運用を助けるAzure SRE Agentが公開プレビューとなりました。これは、システムに問題が発生した際に、自動で原因を特定し、応急処置まで行ってくれる「自律型SREエージェント」です。運用エンジニアの負担軽減に繋がります。

ビジネス現場では、Microsoft 365 Copilotの一般提供（GA）が開始されました。OfficeアプリなどでAIが文章作成やデータ分析を助けてくれるだけでなく、Webや社内データに基づいた高度な情報収集や、専門家のような働きをするエージェントも利用可能になります。

さらに、AIエージェントの開発・活用を加速させるための発表が多数ありました。

AIモデルの基盤となるサービスや環境も進化しています。

これらの発表から、MicrosoftがAI、特に複数のAIエージェントが連携して自律的に働く「agentic web」の世界を強く推進していることが分かります。開発者は、AIをより身近に、かつ強力なツールとして活用し、これからのソフトウェア開発やシステム運用が大きく変わっていくことを予感させる発表の数々でした。

引用元: https://zenn.dev/galirage/articles/microsoft-build-2025

AIエージェントの開発が進み、LinkedInやUberなどの企業もLangGraphを使ってエージェントを構築しています。LangGraphはエージェントを信頼性高く作るための良い仕組みを提供していますが、作ったエージェントを実際に動かす「デプロイ」は、エージェントの種類によっては難しくなることがあります。

特に、処理に時間がかかる（長時間実行）、急にたくさんのリクエストが来る可能性がある（バースト性）、会話の内容など以前の状態を覚えておく必要がある（状態保持）といった特徴を持つエージェントのデプロイは複雑になりがちです。

LangGraph Platformは、このような難しいエージェントのデプロイを簡単にするために作られました。

具体的にどのような課題を解決するのでしょうか。

長時間実行のエージェント:

バースト性のエージェント:

状態保持のエージェント:

このように、LangGraph Platformを使うことで、開発者はデプロイに伴う様々な技術的な課題（通信、エラー処理、負荷対策、状態管理など）に頭を悩ませることなく、AIエージェント自体の「賢い動き」を作ることに集中できるようになります。

引用元: https://blog.langchain.dev/why-langgraph-platform/

Google AI Studioは、Googleの最新AIモデル「Gemini」を使った開発を始めるための便利なツールです。今回のアップデートで、開発体験が大きく向上し、特に新人エンジニアの方にも分かりやすく、AI開発をスムーズに進められる機能がたくさん追加されました。

一番注目すべき機能強化は、強力なコード生成機能です。高性能なGemini 2.5 Proモデルを活用し、プロンプト（指示）を与えるだけで、Webアプリケーションのコードを自動生成できます。開発途中のコード修正もチャット形式で指示でき、変更点の確認や過去の状態への復帰も簡単です。作ったアプリは、Google CloudのCloud Runにワンクリックで公開（デプロイ）できます。AIがコード作成をサポートしてくれるので、アイデアを素早く形にするのに役立ちます。

また、画像や動画、音声、音楽といった様々なメディアを生成する機能も強化されました。「Generate Media」ページで、画像・動画生成モデル（Imagen, Veo）、新しい音声生成モデルがまとめて使えます。インタラクティブな音楽生成ができるLyria RealTimeも利用可能です。AIを使って、様々な種類のコンテンツを生成できるようになり、表現豊かなアプリケーション開発が可能になります。

会話AIの開発もしやすくなりました。Gemini 2.5 Flashのプレビュー機能で、Live APIがネイティブオーディオをサポート。自然な声色で応答したり、話者と背景音を聞き分けたりできます。テキストから音声を合成するTTS機能も強化され、複数の話者や話し方を調整可能です。より人間らしい、自然な対話ができるAIエージェントを作るための基盤が整いました。

さらに、他のツールや外部の情報との連携も考慮されています。Model Context Protocol (MCP)をサポートし、オープンソースツールとの連携が簡単になりました。「URL Context」という新しいツール（実験段階）では、WebサイトのURLをAIに与えることで、その内容を読み取って要約したり参照したりできます。情報収集やコンテンツ作成に役立ちそうです。

今回のGoogle AI Studioの機能強化により、AIモデルを使ったアプリケーション開発がより手軽に、そして多様な表現が可能になりました。これからAI開発を始めてみたい新人エンジニアの皆さんにとって、非常に強力な味方になるはずです。ぜひGoogle AI Studioを試して、最新のAIモデルでどのようなことができるか体験してみてください。

引用元: https://developers.googleblog.com/en/google-ai-studio-native-code-generation-agentic-tools-upgrade/

国土交通省が、人気ゲーム「マインクラフト」を使って巨大な地下施設「首都圏外郭放水路」を再現しました。これは、子どもたちに治水や防災の仕組みを楽しく学んでもらうための公式プロジェクトです。再現されたワールドデータは公開されており、ダウンロードして自由に探索できます。ゲームという身近な技術が社会インフラの理解促進に活用される、面白い取り組みとして注目されています。

引用元: https://togetter.com/li/2554155

VOICEVOX:ずんだもん