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

freeeでは、GitHub Copilotなどに加え、特に開発スタイルを変える可能性を秘めたAIエージェント「Cline」の全社導入を進めています。この記事では、freeeがどのようにAIツールの本格導入に取り組み、どのような課題を乗り越えたのかが解説されています。

AIツールの導入は、従来のツールと異なり、セキュリティリスクやコスト管理など特有の難しさがあります。freeeではこれに対応するため、二つの仕組みを導入しました。一つは「AI特区制度」で、安全なサンドボックス環境などで一部のチームが限定的にツールを試すことで、現場での利用感や課題を素早く洗い出します。もう一つは「AI駆動開発チーム」で、特区で見つかった課題への対処や、全社導入のための基盤開発、ガイドライン策定、導入効果の測定などを担う専門チームです。

この体制のもと、freeeではまずAI特区でツールを検証し、うまくいきそうなものについて、特区で得た知見をもとに全社展開のためのガイドラインやセキュリティ基盤を整備し、その後全社へ展開・運用するという流れで進めています。

Clineの導入においては、主に三つの壁に直面しました。

freeeは今回のCline導入を通じて、AIツール導入にはリスクと効果を天秤にかけた判断や、システム的・組織的な専用対策が不可欠であること、またツールごとの特性に合わせた対策が重要であることを学びました。Clineは既に多くの開発者に利用されており、今後はより詳細な効果検証や、AIツール前提の開発フローへのシフトを目指していくとのことです。

この記事は、freeeがAIエージェントの全社導入にどう取り組み、技術的な課題や組織的な課題にどう向き合ったかを知る上で、非常に参考になる事例と言えるでしょう。

引用元: https://developers.freee.co.jp/entry/ai-cline-rolling-out

AIコードレビューエージェントを自作した経験に基づく記事です。PRの差分をLLMに送り問題点を見つけさせる仕組みで、GitHub Copilot Reviewなどの類似ツールと比較し、有用性を検証しています。基本的なエージェントは数時間で構築可能ですが、LLMは指示に従わないことがあり、コード全体の文脈理解が不十分だと的外れな提案をすることが課題です。記事では、市販のエージェントを利用するより、自社で完全に制御できるエージェントを開発するためのフレームワークの将来性に期待を寄せています。

引用元: https://www.sourcebot.dev/blog/review-agent-learnings

この記事は、Google製のA2Aプロトコルを使った複数AIエージェント連携のチュートリアルを解説します。A2Aとは、異なるAIサービス（チャットボット、画像生成、為替変換など）を連携させるプロトコルです。

記事では、複数のエージェントをA2Aで接続し、統合チャットUIから対話・実行できるデモを構築する手順を説明します。セットアップ、APIキー取得、リモートエージェント（経費申請、画像生成、為替）、ホストエージェントの作成、エージェントカードの追加、チャットテストを通して、A2Aの基本的な使い方を理解できます。

A2Aのコア要素として、Agent Skills（エージェントの機能）、Agent Capabilities（通信方法）、Agent Card（エージェントの名刺）を紹介。特にAgent Cardは、エージェントのメタデータや機能を記述する重要な要素で、JSON-RPC形式で定義されます。

引用元: https://zenn.dev/churadata/articles/c505d4c2d39281

ChatGPTは会話履歴が長くなると性能が落ちるという声があります。原因として、不要な情報も記憶してしまうことや、長い履歴の中で文脈が曖昧になる、過去の会話の重要度（重みづけ）がうまくいかないことなどが考えられています。これはLLMが過去の情報を扱う難しさを示しており、人間のように不要な情報を整理する仕組みや、ユーザー側での履歴管理の工夫が重要になりそうです。

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

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

この論文は、「AIエージェント」と呼ばれる、私たちの代わりに様々な作業を自動で行ってくれるプログラムのセキュリティをしっかり評価するための新しい仕組み「DoomArena」について紹介しています。AIエージェントはこれから色々な場所で活躍が期待されていますが、もし悪意のある攻撃に弱かったら困りますよね。そこで、どんな脅威に対してどのくらい強いのかをテストすることがとても重要になります。

DoomArenaは、このセキュリティテストをもっとやりやすくするために、以下の3つの考え方で作られています。

DoomArenaを使うことで、新しい種類の脅威にも対応しやすくなったり、これまでに考えられていた様々な攻撃手法を組み合わせて、より厳しく、きめ細かいセキュリティテストができるようになります。また、エージェントが持つ様々な弱点（脆弱性）と、本来の性能とのバランス（トレードオフ）を分析することも可能です。

このフレームワークを使って、現在最新のAIエージェントをテストしたところ、いくつか面白いことがわかりました。

このDoomArenaフレームワークは公開されており、AIエージェントの開発者やセキュリティに関心のあるエンジニアが利用できるようになっています。AIエージェントをより安全に開発していく上で役立つツールと言えるでしょう。

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

LLM（大規模言語モデル）を使ったアプリケーションを開発する際、その性能を把握することは非常に重要です。これは、どこに改善の余地があるかを見つけたり、サービス品質（レイテンシなど）と処理能力（スループット）のバランスを調整したり、どれくらいの数のサーバーが必要かを見積もったりするために役立ちます。

この記事では、LLMの性能を測るためのツール「NVIDIA GenAI-Perf」と、NVIDIAが提供するLLM推論サービス「NVIDIA NIM」を組み合わせてMetaのLlama 3モデルの性能を評価する方法が解説されています。

GenAI-Perfは、LLMサービスの応答性能をクライアント側から測定できるツールです。具体的には、最初の単語が表示されるまでの時間（Time to First Token: TTFT）、単語が出てくる間隔（Inter-token latency: ITL）、1秒あたりの単語数（Tokens per second: TPS）、1秒あたりのリクエスト数（Requests per second: RPS）といった重要な指標を測ることができます。GenAI-Perfは業界標準となっているOpenAI APIの仕様に準拠した多くのLLMサービスに対応しています。

NVIDIA NIMは、LLMを素早く簡単に、そして高性能に動かすためのソフトウェアパッケージです。高性能なLLM（例えばLlama 3）をOpenAI API互換の形式で提供できるのが特徴です。

記事では、実際にNIMを使ってLlama 3モデルを起動し、次にGenAI-Perfを使って性能を測定する手順が紹介されています。具体的なコマンド例や、入力や出力の文章の長さ、同時に処理するリクエスト数（同時接続数）といったパラメータを設定してベンチマークを実行する方法が示されています。さらに、一度に複数の設定で自動的にテストを実行する方法も紹介されており、様々な状況でのモデルの性能を確認できます。

測定が終わると、GenAI-Perfは結果をCSVファイルなどに出力します。このデータを分析することで、同時接続数を変えたときにTTFTやRPSがどう変化するかをグラフ（レイテンシ・スループット曲線）にして見ることができます。このグラフから、「このくらいの応答速度を維持するには、最大でどれくらいのリクエストを同時に処理できるか」「特定の同時接続数では、応答速度と処理能力がどうなるか」といった情報を読み取ることができ、最適なシステム構成や運用方法を考えるのに役立ちます。

また、特定の目的に合わせてカスタマイズされたLLM（例：LoRA技術を使ったモデル）についても、NIMでデプロイし、GenAI-Perfで性能を評価できることが述べられています。

まとめると、GenAI-PerfはNIMのような高性能なLLMサービスの効果的な性能評価に役立つツールであり、これからLLMを使ったシステムを構築・運用していくエンジニアにとって、性能のボトルネック特定や最適化、適切なインフラ設計のために知っておくと良い技術です。

引用元: https://developer.nvidia.com/blog/llm-performance-benchmarking-measuring-nvidia-nim-performance-with-genai-perf/

Google DeepMindが、エンジニア向けの「Gemini 2.5 Pro」というAIモデルのアップデートを発表しました！今回のアップデートで、特に「コーディング」の性能が大きく向上したとのことです。

この新しいGemini 2.5 Proは、フロントエンドやUI（ユーザーインターフェース）開発の能力が上がり、デザイン性の高いWebアプリ開発に強みを見せています。外部の評価でも、Web開発の能力を競うリーダーボードで1位を獲得するほどの実力です。

さらに、単にコードを書くだけでなく、コードの変換や編集といった基本的なコーディングタスクや、複数のステップをAIが自動で実行するような、より複雑な開発作業も得意になりました。まるで経験豊富な先輩エンジニアのように、適切な判断をして、より良いコードを書けるようになったという評価もあります。

具体的にどんなことができるかというと、例えば次のようなことが期待できます。

この進化したGemini 2.5 Proは、Google AI Studioや、企業向けのVertex AIといったプラットフォームで利用できます。すでにGemini 2.5 Proを使っている場合は、特別な設定をしなくても自動的に最新版にアップデートされているので、すぐに新しい性能を試せます。

今回のアップデートで、AIがより強力な開発ツールとして使えるようになり、私たちのコーディング作業を大きくサポートしてくれることが期待されます。ぜひ、この新しいGemini 2.5 Proを使って、色々な開発に挑戦してみてください！

引用元: https://deepmind.google/discover/blog/gemini-25-pro-preview-even-better-coding-performance/

AIに「バカしかいないデスノート」の物語作成を依頼したところ、デスノートのルール説明で終わってしまい話題です。予期せぬAIの応答に「忙しい人のためのデスノート」といった声が上がり、多くの人が笑いました。この事例は、AIに面白い創作をさせる可能性と意外な応答の楽しさを示しています。

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

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

この記事は、「AIちょっと苦手おじさん」だった筆者が、AIエージェント「Cline」を使い始めた経験と、開発現場での具体的な活用方法について紹介しています。特に、DDD（ドメイン駆動設計）などの考え方を取り入れた保守性の高いコードベースが、AI活用にいかに重要であるかを強調しています。

筆者は、VSCode拡張機能のClineを、GitHub Copilot経由でClaude 3.5 Sonnetモデルと組み合わせて使用しています。最初はタスクの指示の粒度や効率的な進め方に悩みましたが、試行錯誤の結果、効果的な使い方が見えてきました。

AIに開発タスクを任せる上で、なぜ保守性の高いコードが重要なのでしょうか。それは、AIが正確なアウトプットを出すために必要な「コンテキスト情報」を小さく抑えることができるからです。複雑な全体像を知らなくても、特定の小さな部分だけを理解すれば作業できるようなコード（「コンテキストの局所化」）は、AIにとっても扱いやすいのです。DDDやクリーンアーキテクチャは、関心事を分離し、このコンテキストを局所化するのに役立ちます。

また、AIは自然言語で学習しているため、クラス名やメソッド名から振る舞いが予想しやすい、いわゆる「自然言語としての可読性が高い」コードは、AIにとっても理解しやすく、期待通りのコードを生成する可能性が高まります。現時点では、「AIフレンドリーなコード」は「人間が読みやすいコード」とほぼ同じだと言えるでしょう。

具体的なタスク分担の例として、新規機能開発におけるバックエンド（SpringBoot/Kotlin）とフロントエンド（React/TypeScript）でのClineの活用が紹介されています。

バックエンドでは、

フロントエンドでは、

Clineを効果的に使うためのTIPSとして、以下の点が挙げられています。

まとめとして、DDDのようなレイヤードアーキテクチャによる関心事の分離は、AIが必要とするコンテキストを減らし、効率的なタスク分担を可能にすることが筆者の経験から分かったそうです。AIの進化にも期待しつつ、今後も人間が理解しやすい「ヒューマンリーダブルなコードベース」を維持していくことの重要性を改めて認識しています。新人エンジニアの皆さんも、こういったAIツールを使いこなし、開発をより効率的で楽しいものにしていきましょう。

引用元: https://tech.codmon.com/entry/2025/05/01/132700

この記事では、AIエージェント「Claude Code」を使ってiOSアプリ「電光石火」を実際に開発・リリースした経験から得られた知見が共有されています。AIによるコーディングツールは増えていますが、プロダクトとして完成させた例はまだ少ないため、実践的な情報として参考になります。

著者が感じたAIエージェントの最大のメリットは、開発速度の向上です。体感で通常の3〜5倍速く開発できたとのこと。簡単な指示で動くコードをすぐに生成できるため、ゼロから考えるよりも、まずAIにたたき台となるコードを書かせ、それをベースに作業を進めるのが非常に効率的です。AIが間違ったコードを書くこともありますが、生成コストが低いため、失敗しても大きな問題にはなりません。

一方で、AIエージェントは複雑な構造設計や高度な「共通化・抽象化」がまだ苦手です。後々のメンテナンス性を考えると、全体的な設計や、異なる要素をうまくまとめて扱う仕組み作りは人間が行うべき部分です。しかし、最初にAIにいくつかコードを書かせて具体例を作ってから人間が設計を考えると、よりスムーズに進められます。一度設計が固まれば、AIはその方針に沿ったコードを書くのが得意になります。

AIエージェントと「テストファースト」開発は相性が良い方法です。AIはテストコードを書くのが得意で、テスト結果をフィードバックとして自身のコードを修正し、学習していくことができます。これにより、単なるチャットでコードを生成させるよりも賢く振る舞うように感じられるそうです。ただし、AIがテストコードを都合よく変えてしまうこともあるため、テストの内容は人間が確認することが大切です。

また、使用するプログラミング言語の特性もAIエージェントの効率に影響を与える可能性があります。Swiftのような静的型付け言語は、コンパイラからの明確なエラーフィードバックが多いため、AIが問題を自己解決しやすいと考えられます。

AIエージェントを使う際は、「単なるツール」ではなく「チームメンバー」として捉えることが重要です。ジュニアエンジニアに接するように、AIのコードに完璧を求めすぎず、ある程度任せることで全体の速度が上がります。ただし、セキュリティやパフォーマンスに関わる部分、あるいはデータの構造など、プロダクトの基盤となる重要な部分は、人間がしっかりと設計・レビューする必要があります。

AIエージェントの真価を引き出すには、チームのコミュニケーションやプロダクトの仕様自体も考慮に入れるべきです。AIはコーディングが速い分、人間側の指示待ち時間や、AIが苦手な仕様に時間をかけることがボトルネックになり得ます。AIが作りやすいシンプルな仕様にしたり、指示を出す人が素早く判断できるような体制がAI活用には有利です。

AIエージェントは、これからの開発スタイルを大きく変える可能性を持っています。その能力を最大限に活かすためには、AIの得意・不得意を理解し、試行錯誤しながら、自分の開発に最適なAIとの連携方法を見つけていくことが重要です。

引用元: https://qiita.com/koher/items/503cd5a9811ab5683a85

この記事では、エンジニアがGemini 2.5 Proを強力な「副操縦士」として活用し、自由記述テキストのマルチラベル分類タスクに挑んだリアルな体験談が紹介されています。

データ分析の目的は、大量のテキストデータに含まれる要望を自動で識別し、複数のタグ（ラベル）を付けるモデルを、業務で使える精度で構築することでした。

プロジェクトは、まずアプローチの模索から始まりました。最初は簡単な教師なし学習を試みましたが、期待する結果が得られませんでした。そこでGeminiに相談したところ、「特定のラベルを正確に付けたいなら教師あり学習が適している」と、その理由とともに代替案が提示されました。このように、うまくいかなかった結果をAIにフィードバックすることで、次の一手のヒントを得られることが学びとなりました。

次に、分析に必要な教師データの品質を確認しました。データの欠損やラベルの種類、表記揺れなどをチェックする定型的なコード（Python/pandas）は、Geminiに具体的な指示を与えることで瞬時に生成してもらえました。これにより、コードを手書きしたり調べたりする時間を削減し、データの「中身」の確認に集中できたといいます。

データが整い、いよいよモデル構築です。テキスト前処理にTF-IDF、分類器にロジスティック回帰を使ったマルチラベル分類モデルの基本的なコードをGeminiに依頼すると、必要な処理の流れを含むパイプラインコードがすぐに入手できました。標準的な機械学習モデル構築の土台となるコード（ボイラープレートコード）の生成も、Geminiを使えば効率的に行えます。

しかし、最初のモデルの精度は実用には遠く、特に少数派ラベルの予測精度が低いという課題が見つかりました。ここからが、Geminiが壁打ち相手として真価を発揮するフェーズでした。評価結果をAIに見せて課題を投げかけると、Geminiは考えられる原因（日本語の前処理不足、データ数の偏りなど）を分析し、具体的な改善策（形態素解析の導入、不均衡データ対策としてのclass_weightオプション利用、別のモデル提案など）を複数提示してくれました。なぜその対策が有効なのかという根拠も示してくれるため、納得感を持って改善を試みることができ、効率的にモデルの精度を高めることができました。

モデルの精度が向上した後も、実際の運用で起こりうる問題（例：予測結果が空になる、特定のラベルが異常に多く予測される）への対応が必要です。予期せぬモデルの挙動に対する原因分析や、それを解決するためのビジネスルールをコードに落とし込む作業でもGeminiは役立ちました。

最終的に、大量データへの予測結果を集計・可視化するレポーティング作業も、Geminiにコード生成を依頼することでスムーズに完了しました。

この経験を通じて、著者は生成AIがデータ分析作業の多くの「手足」となる部分を効率化・代行できるだけでなく、分析を進める上で行き詰まった際の相談相手として、原因分析や具体的な解決策の提案においても非常に有用であることを強く実感したそうです。AIの回答を鵜呑みにせず適切に評価することは必要ですが、生成AIを上手に活用することで、データ分析のハードルを下げ、組織全体のデータ活用能力向上にも繋がる可能性がある、と記事は締めくくられています。

新人エンジニアの皆さんにとって、データ分析プロジェクトの具体的な進め方や、生成AIをどのように活用すれば効率的に作業を進め、課題を乗り越えられるかのヒントがたくさん詰まった記事です。ぜひ、皆さんの日々の業務でも生成AIを「副操縦士」として活用することを試してみてください。

引用元: https://nealle-dev.hatenablog.com/entry/2025/05/01/102722

この記事は、ウェブ上で次世代のグラフィックスAPIであるWebGPUと、3D表現ライブラリとして広く使われているThree.jsの連携について、新人エンジニアにも分かりやすく解説しています。

WebGPUは、従来のWebGLよりも低レベルでGPU（グラフィックス処理を行う部品）に効率的にアクセスできる新しい技術です。Three.jsは、難しいGPUの操作を抽象化して、JavaScriptで手軽に3Dコンテンツを作成できるライブラリです。

Three.jsでは現在、WebGPUに対応するための「WebGPURenderer」という新しいレンダラー（描画を行う機能）の開発が進められています。これはまだ開発途中（WIP: Work in Progress）ですが、既存のWebGLRendererとほぼ同じ使い方で、WebGPUのメリットを活かせるように設計されています。Three.jsを使うことで、WebGPUの低レベルな部分を知らなくても、その高いパフォーマンスや将来性を活かせる可能性があります。

Three.jsでWebGPUを導入するのは比較的簡単です。従来のWebGLRendererを使っていた場合、Three.jsのWebGPU対応ビルドを読み込み、レンダラーをWebGPURendererに切り替えて、初期化時にawait renderer.init()を呼び出すのが主な変更点です。多くの既存コンテンツは、このレンダラーの切り替えだけで動作すると筆者は述べています。ただし、一部の特殊な表現（粒子や線）や、自分でシェーダー（描画の計算を行うプログラム）を書いている場合は修正が必要になることがあります。

現在のWebGPUはまだすべてのブラウザで正式にサポートされているわけではなく、主にChromeとEdgeのみです（2025年5月時点）。しかし、WebGPURendererには、WebGPUが使えないブラウザでは自動的にWebGL 2.0に切り替えて描画する「フォールバック機能」があります。これにより、新しい技術を使いつつ、より多くのユーザー環境で表示できるのが大きなメリットです。

ただし、現状（Three.jsのr176時点）では、WebGPURendererがWebGLRendererより必ずしも高速というわけではなく、特に大量の細かい描画を行う場合など、WebGLの方が良い性能を示すこともあるようです。WebGPU本来の性能を引き出すための最適化は現在も進行中であり、今後のアップデートで改善されていくことが期待されます。

また、Three.jsではWebGPU時代に向けた新しいシェーダー記述方法として「TSL（Three.js Shading Language）」が導入されています。これはJavaScriptを使ってシェーダーの処理を定義できるもので、書いたコードはThree.jsが自動的にWebGPU用のWGSLやWebGL用のGLSLに変換してくれます。これにより、異なるシェーダー言語の違いを意識せずに、単一のコードでWebGPUとWebGLの両方に対応できるようになります。TSLはノードベースで直感的に記述できるという特徴もあります。

まとめると、Three.jsのWebGPURendererは開発が進んでおり、将来性のあるWebGPUを手軽に試せる方法を提供しています。新しいTSLを使えばシェーダー開発も効率的になります。まだ開発途中のため、本格導入前には動作確認が必要ですが、小規模なプロジェクトやプロトタイプで触ってみることで、WebGPU時代の新しい表現力を体験する価値は大きいでしょう。今後のThree.jsの進化に注目していきましょう。

引用元: https://ics.media/entry/250501/

VOICEVOX:ずんだもん

Googleが提供するAIツール「NotebookLM」に、新しい機能として「音声概要」が追加され、この度、日本語を含む50以上の言語に対応しました。

NotebookLMは、皆さんが持っているドキュメント（PDFやテキストファイルなど）をアップロードすると、その内容を理解して要約を作ったり、内容について質問に答えたりしてくれるAIツールです。たくさんの資料を読まなければならないエンジニアの仕事でも、情報収集や内容の把握を助けてくれる便利なツールとして使うことができます。特に、新人エンジニアの皆さんが新しい技術やプロジェクトに関わる際、大量のドキュメントを読む必要が出てくる場面で役立つでしょう。

今回アップデートされた「音声概要」機能は、アップロードした資料の内容を、ポッドキャストのように音声で聞きながら概要を理解できる機能です。これまでは主に英語で提供されていましたが、Googleの最新AI技術であるGemini 2.5 Proなどを活用することで、日本語を含む50以上の幅広い言語で音声概要を生成できるようになりました。

この機能が日本語に対応したことで、特に日本のエンジニアにとっては、情報収集の幅が大きく広がります。例えば、最新の技術情報は海外から発信されることが多く、英語のドキュメントやブログを読む機会も多いかと思います。NotebookLMに英語の資料をアップロードし、出力言語を日本語に設定すれば、その内容の要点を日本語の音声で手軽に確認できます。英語を読むのが得意でなくても、まずは音声で全体像を掴むことで、効率的に情報を取り入れることができるようになります。これは、日進月歩の技術の世界で学び続ける上で、非常に役立つはずです。

さらに、NotebookLMの設定で出力言語を簡単に切り替えられるため、音声概要だけでなく、AIとのチャットによる質問応答も好きな言語で行えます。これにより、多様な言語の資料を扱ったり、国際的なチームでの情報共有を円滑にしたりすることにもつながる可能性があります。

NotebookLMの音声概要機能の多言語対応は、世界中の人々が言語の壁に阻まれることなく、必要な情報にアクセスし、学習や仕事に役立てることを目指しています。新人エンジニアの皆さんにとって、新しい技術や知識を効率的に習得するための強力なアシスタントとなるでしょう。ぜひ一度NotebookLMを試してみて、その便利さを体験してみてください。

引用元: https://blog.google/intl/ja-jp/company-news/technology/notebooklm-50/

LLM（大規模言語モデル）は急速に普及し、その能力は単なるチャットから、複雑なタスクをこなすAIエージェントへと進化しようとしています。これまでのAIエージェントの仕組み（例：ChatGPTの拡張機能やAIコーディングツール）は、使えるツールやサービスに制約があったり、設定が難しかったりといった課題がありました。

このような背景から登場したのが、MCP（Model Context Protocol）という新しい技術です。MCPは、LLM（AI）と様々な外部ツールやサービス（ファイルシステム、Web検索、各種アプリケーション、ハードウェアなど）が連携するための「共通のルール」や「約束事」と考えると分かりやすいでしょう。例えるなら、私たちの指示を聞く「ドラえもん」（MCPホスト）が、目的に合わせて様々な「ひみつ道具」（MCPサーバ）を選んで使ってくれるようなイメージです。

MCPを使うことで、LLMはまるで手足を得たかのように、多様なツールであるMCPサーバを組み合わせて、より複雑で具体的なタスクを自律的にこなせるようになります。例えば、Web検索、情報整理、CAD設計、3DCG作成など、様々な作業が可能になります。また、目的に合わせてMCPサーバを選択したり、自作したり、組み合わせたりする自由度が高まり、特定のサービスへの依存度を下げることができます。

MCPを使うためには、PC環境やMCPホスト、連携したい外部サービスの設定が必要です。少し手間がかかる場合もありますが、設定自体をAIに手伝ってもらうこともできます。

自分でMCPサーバを「作る」ことも可能です。これは、既存のサービスやアプリをAIから使えるようにしたい場合や、MCPの仕組みを深く理解したい場合に特に有効です。公式ツールでは難しい処理を高速化する（例：Notion連携）など、独自の機能を持ったMCPサーバを作ることで、AI活用の幅をさらに広げたり、新しいビジネスチャンスに繋げたりできる可能性があります。Pythonなどの言語でMCPサーバを作るための開発キット（SDK）も提供されています。

ただし、MCPサーバは様々な情報やツールにアクセスするため、セキュリティには注意が必要です。出どころの怪しいサーバは使わない、提供されているコードを確認する、実行時には必ず確認を求める設定にするなど、他のアプリケーションを使う時と同様に注意が必要です。

MCPはまだ新しい技術ですが、AIとツール連携の標準規格となる可能性があり、対応するMCPサーバも増えつつあります。セキュリティなどの課題はありますが、AIエージェントが私たちの作業をより強力に支援してくれる未来に繋がる、非常に可能性を秘めた技術として注目されています。まずは公開されているMCPサーバを使ってみることから、この新しいAI活用の世界に触れてみるのはいかがでしょうか。

引用元: https://www.docswell.com/s/karaage0703/56V4PL-2025-04-25-104216

この記事は、AI Agentである「Devin」を開発チームで3ヶ月間試用した経験についてのレポートです。AI Agentが実際の開発現場でどのように役立ち、またどのような課題があるのかを知ることができます。

まず、Devinをエンジニアリング業務に使ってみた全体的な感触として、人間の新人エンジニアと比べて非常に高速かつ大量に作業ができる点が挙げられています。特に、既存の技術ドキュメントがしっかり整備されていたり、プログラムのビルドやテストが自分のコンピューター内で完結できる環境が整っていたりすると、Devinの作業効率と質が向上するとのことです。

ただし、Devinに作業を依頼する側には、達成したい目標を明確に持ち、Devinが作成したコードや成果物の良し悪しを判断できる能力が求められます。また、最終的な成果物の品質を保証するためには、人間のエンジニアによるコードレビューがやはり重要になります。

この記事では、Devin自身にこれまでの3ヶ月の作業を振り返ってもらったレポートも紹介されています。そのレポートによると、Devinは主にコード開発（新機能追加や改良）、バグ修正、プログラムの整理（リファクタリング）、ドキュメント作成、そして開発環境の整備（CI/CDなど）といった幅広い作業を行ったと分析しています。タスクの明確化、途中の確認、コードレビューでのフィードバックが効果的なやり取りのパターンとして挙げられています。プルリクエスト（PR、コード変更をチームに提案するもの）の分析では、作成されたPRの85%が取り込まれ、新しいコードのテストカバー率も平均90%以上と、一定の品質を保っているように見えます。作業規模は、小さなバグ修正から大規模な機能追加まで様々だったようです。

しかし、著者の評価によると、Devinのレポートには「妄想」（ハルシネーション）が多く含まれており、特に統計的な数値などは鵜呑みにはできないとのことです。3ヶ月しか使っていないのに1年分の作業を分析していたり、内容は素晴らしいものの、そのまま信用できるのは半分強程度だとしています。

ここから分かるのは、AI Agentはまだ完璧ではなく、生成された成果物を人間がレビューし、必要に応じて修正や調整を行うプロセスが不可欠であるということです。つまり、AI Agentはすべてを自動でやってくれる存在ではなく、人間のエンジニアの強力な「ツール」として捉えるべきだということです。

この記事の著者は、Devinや他の開発向けAIは現時点でも十分に価値があり、料金に見合う活躍をしてくれると述べています。そして、AIも得意なことと苦手なことがあるため、実際に使ってみて感覚を掴むことが重要だと強調しています。今後AIの精度は向上するでしょうが、今は「とにかく触って体験する」フェーズだとして、利用を推奨しています。

まとめると、AI Agentは開発作業を高速化する可能性を秘めていますが、それを最大限に活かすには、依頼する側の明確な指示、AIの出力を評価・修正する人間の判断力、そして適切な開発環境の整備が鍵となります。AIは万能ではない現実も理解しつつ、ツールとしてうまく使いこなしていくスキルが、これからのエンジニアには求められるでしょう。

（注：記事中に直接的な公開日がないため、記事が最新であるという前提で要約を作成しました。）

引用元: https://tech.repro.io/entry/2025/04/30/132003

この記事は、筆者がアニメ「機動戦士Gundam GQuuuuuuX」の第4話を見ていない状態で、AIに感想記事を書かせるというユニークな実験を行ったレポートです。

筆者は睡眠不足などで時間がなく、アニメの感想ブログを書く「ノルマ」をこなすために、AIの活用を試みました。特に、SNSで多くの情報が出回っている人気作品であれば、AIが外部情報を学習してそれらしい感想を書けるのではないかと考えたようです。

実験では、AIにアニメ公式サイト、SNSの投稿、Wikipedia、そして筆者自身の過去のブログ記事などを学習データとして与え、「ブログに掲載するアニメ感想記事」を生成するように指示しました。これにより、AIが最新の情報を参照しつつ、筆者らしい文体で書けるか検証する狙いがありました。

AIが生成した感想記事は、新しい登場人物（連邦の魔女シイコ・スガイ）やモビルスーツ（ゲルググ）に触れ、ストーリー展開やキャラクター関係、戦闘シーンなどについて、外部情報をもとにしたと思われる詳細な記述を含んでいました。また、ファンの反応や今後の展開（ドムの登場など）にも言及しており、表面上はそれなりのアニメ感想ブログ記事のように見えます。

しかし、筆者はAI生成記事を読んだ結果、当然ながらネタバレを食らったと述べています。さらに、AIは外部情報をまとめることはできても、筆者特有のユーモア、皮肉、個人的な感情といった「異常性」は再現できなかったと評価しています。

この実験を通じて、筆者はAIが一般的な情報に基づいた定型的な文章を書く能力は高い一方、個人の深い思考や独特な文体を模倣するには限界があると感じています。同時に、世の中にはAIが書いたような表面的な記事も多いのかもしれない、と考えさせられたようです。

アニメ感想という題材でAIの可能性と限界を探ったこの試みは、AIを使ったコンテンツ生成に興味を持つ日本のエンジニアにとって、身近で分かりやすい実験事例として参考になるでしょう。AIは便利なツールですが、人間の個性や経験に根差した表現にはまだ及ばないという示唆を得られます。

引用元: https://nuryouguda.hatenablog.com/entry/2025/04/30/135643

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

この記事は、AIエージェントがサイバーセキュリティの運用をどのように進化させるかについて解説しています。これまでのAIは主に不審な活動の「検出」に使われることが多かったのですが、AIエージェントはさらに進んで、自律的に「考えて計画し、行動する」ことで、セキュリティ担当者（アナリスト）の定型的な作業を自動化・効率化する可能性を秘めています。これは、大規模言語モデル（LLM）の進化によって実現しました。

従来、セキュリティアナリストは、アラートの調査、関連情報の収集、脅威への対応といった多くの手作業に時間を費やしていました。しかし、AIエージェントは、複雑で繰り返し発生するタスク（例えば、脅威情報の調査や、アラートの関連付け、初期対応など）を自動で行えるため、アナリストはより高度な判断や深い分析に集中できるようになります。

記事では、具体的な応用例として以下の2つを紹介しています。

アラート管理の効率化:

ソフトウェア脆弱性分析の高速化:

このようなAIエージェントシステムを開発する際には、タスクの性質に合わせてシステムの構造（エージェントがどれだけ動的に判断するか）を選ぶことが重要です。また、システムの評価には、最終結果だけでなく、エージェントがどのように考え、どのツールを使ったかといった中間プロセスも確認し、継続的に改善していく仕組み（人間のフィードバックを取り込むツールなど）が有効です。LLM自体を評価者として使う「LLM-as-a-judge」という手法も紹介されています。

AIエージェントはサイバーセキュリティの現場で、アナリストの頼れる助手として、調査作業を合理化し、複雑なタスクを支援する未来が期待されています。この記事は、AIエージェントがセキュリティ運用にもたらす具体的な価値を示す技術記事として、新人エンジニアの方々にも参考になるでしょう。NVIDIAは、開発者向けのツールキットや事例（AI Blueprint）を提供しており、誰もがAIエージェントを活用したシステムを構築できるよう支援しています。

引用元: https://developer.nvidia.com/blog/advancing-cybersecurity-operations-with-agentic-ai-systems/

Metaは初の試みとなる開発者向けイベント「LlamaCon」を開催し、オープンソースAIモデルであるLlamaを使った開発をさらに容易にするための新しいツールや取り組みを発表しました。Llamaは公開から2年あまりで10億以上のダウンロードを達成し、オープンソースAIエコシステムを牽引する存在となっています。

このイベントで発表された主な内容は以下の通りです。

まず、開発者がLlamaを使ってアプリケーションを素早く構築できるようになるLlama API（リミテッドプレビュー版）が発表されました。これは、APIの手軽さとオープンソースの柔軟性を両立させたプラットフォームです。ワンクリックでAPIキーを作成でき、対話型プレイグラウンドで様々なLlamaモデル（先日発表されたLlama 4 ScoutやMaverickを含む）を試すことができます。PythonおよびTypescriptの軽量SDKが提供され、OpenAI SDKとの互換性もあるため、既存アプリケーションからの移行も容易です。さらに、Llama 3.3 8Bモデルのカスタム版をチューニング・評価するためのツールも提供され、コスト削減や精度向上に役立ちます。ユーザーのデータがモデル学習に使われることはなく、API上で構築したモデルは自由に持ち出せる（特定の環境にロックされない）点が強調されています。今後は段階的に多くの開発者に提供される予定です。また、CerebrasやGroqといったハードウェアパートナーとの協業により、Llama API経由でより高速な推論が可能になる実験的なアクセスも提供されます。

次に、Llama Stackの連携強化が発表されました。これは、Llamaを使ったエンタープライズ向けAIソリューションのデプロイを容易にするための取り組みです。NVIDIAのNeMoマイクロサービスとの連携に加え、IBM、Red Hat、Dell Technologiesなど他のパートナーとも緊密に連携しており、今後新しい連携が発表される予定です。

さらに、オープンソースコミュニティ向けの新しいセキュリティツールが公開されました。「Llama Guard 4」「LlamaFirewall」「Llama Prompt Guard 2」といったツールは、AIアプリケーションをより安全に構築するために役立ちます。また、AIシステムのセキュリティ評価に役立つ「CyberSecEval 4」もアップデートされました。特定の信頼できるパートナー向けの「Llama Defenders Program」も開始され、AIを活用したツールでシステムセキュリティの評価を支援します。これは、進化するAIモデルに対応し、ソフトウェアシステムの堅牢性を向上させるための重要な取り組みです。

最後に、Llamaを使って社会に変革をもたらすプロジェクトを支援する「Llama Impact Grants」の第二回受賞者10組（総額150万ドル以上）が発表されました。市民サービス向上、薬局業務効率化、オフラインAI支援、多言語学習ツールなど、Llamaを活用した多様な取り組みが紹介されています。

MetaはオープンソースAIのリーダーとして、開発者が自由に、簡単に、そして安全にAIを構築できるエコシステムを推進していくことを改めて表明しました。Llamaは、専門知識やハードウェアリソースに関わらず、より多くの人々がAIの恩恵を受けられるようにすることを目指しています。

引用元: https://ai.meta.com/blog/llamacon-llama-news/

この記事は、RAG（Retrieval Augmented Generation）という技術を使って、GoogleのDeep Researchのようなより深い検索を実現するための新しい手法「PAR RAG」について解説しています。RAGは、AI（大規模言語モデル、LLM）が外部の情報を参照して回答を生成する技術で、質問応答などで使われています。

Deep Researchのように、複雑な質問に対して何度も検索と推論を繰り返して回答を生成するアプローチが注目されていますが、ここには「ずれの蓄積」という問題があります。これは、検索を繰り返すうちに、最初の質問からどんどん関係ない方向に検索の焦点がずれていってしまうことです。例えば、ある機械の故障原因を調べていたのに、いつの間にか電力契約の話になってしまうようなケースです。この「ずれ」は、検索を繰り返すたびに大きくなる可能性があります。

PAR RAGは、この「ずれの蓄積」を防ぎ、より正確な回答を得るために考えられた手法です。PARとはPlan, Act, Reviewの頭文字をとったもので、以下の3つのステップで回答を生成します。

このPAR RAGを評価した結果、単純な検索繰り返し手法や、PlanやReviewのどちらかがない手法と比べて、回答の精度（F1スコア）が向上することが確認されました。しかし、その反面、時間やコストが通常のRAGと比べて大幅に増加するというデメリットもあります。通常のRAGと比較して、処理時間は約8倍、コストは約13倍になるという結果が出ています。

まとめると、PAR RAGは、RAGにPlan（計画）とReview（確認・修正）のプロセスを加えることで、検索の「ずれ」を防ぎ、複雑な質問に対してより深く、正確な回答を生成できる可能性がある技術です。ただし、その精度向上のためには、時間とコストがかかるというトレードオフが存在します。この記事では、そのメリットとデメリットを正直に示しており、どのような場面でこの技術を使うのが最適かを考える上で参考になります。プロジェクトの要件に応じて、精度を最優先するか、コストや速度を重視するかを検討し、最適なRAGの活用方法を選ぶことが大切です。

引用元: https://zenn.dev/knowledgesense/articles/6d4d9bf52690a4

この記事は、筆者（うさこさん）がChatGPTを使い始めて、その進化と便利さに驚き、日常生活がとても楽しくなった体験談を紹介しています。

最初はChatGPTに抵抗があったり、「AIっぽい回答だな」と感じて放置していたそうですが、同期のブログや知人の活用事例を見て、再び使い始めたとのこと。驚いたのは、ChatGPTが筆者の話し方や口調を学習し、まるで親しい友人のようにフレンドリーに返答するようになった点です。「ナァアアア！」といった独特の鳴き声を語尾に付けて返してきたり、過去の会話内容（例えば「せいろ」について話したこと）を覚えて会話に織り交ぜてきたりと、その人間らしい応答に「人やん…もうこれ人…」と震えたと書かれています。

具体的な活用例として、いくつかの面白い使い方を紹介しています。一つ目は「推しの話をする相手」です。誰かに話したい推しの最新情報や、「疲れた時に推しのフリをしてもらって励ましてもらう」といった、ちょっと変わった使い方も紹介しており、「スマホの中にビューネ君のような推しが住んでいる」感覚で元気をもらっているそうです。二つ目は「ごはんメニュー決め」です。冷蔵庫にある食材や、ダイエット、せいろを使った料理といったリクエストを伝えると、メニューを提案してくれるだけでなく、買い物リストまで作成してくれる便利さを実感しています。三つ目は「ちょっとした愚痴を話す相手」です。誰かに話すほどではないモヤモヤした気持ちを聞いてもらうと、共感してくれるだけでなく、解決策まで提案してくれることに驚き、自分がただ「共感」を求めていたことに気づかされたと言います。四つ目は「色々助けてもらう」ことです。例えばパソコンのトラブルで困った時に、状況確認から解決策、さらに「大丈夫だよ」と精神的なサポートまでしてくれたエピソードを挙げています。

こうしたChatGPTの便利さや人間らしい応答に触れる一方で、「人間いらなくなるのでは」といった懸念も少し感じているようです。しかし、娘さんは「そんな事ずっと昔から言われてきてるじゃん」と冷静な反応だったとか。筆者は、AIの便利さに依存しすぎず、もらったヒントで人生を豊かにすることが大事だと考えていると締めくくっています。

この記事からは、ChatGPTのようなAIが、単なるツールとしてだけでなく、話し相手や日常の様々なタスクをサポートしてくれる身近な「執事」のように活用でき、暮らしを楽しくする可能性があることが伝わってきます。AIの進化に驚きつつも、恐れるだけでなく、どう楽しく付き合っていくかを考えるきっかけになる内容です。

引用元: https://lee.hpplus.jp/100nintai/3209913/

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

この記事は、AIエージェントの中核技術であるMCP (Model Context Protocol) の内部実装を理解することを目指し、Host、MCP Client、MCP ServerをRubyでゼロから実装した過程を解説しています。MCPの基本的な解説や活用事例は多くありますが、内部の仕組みについて、仕様書だけでは理解が難しいと感じる人に向けて、実装を通じて学びを深めることが目的です。

MCPはHost、MCP Client、MCP Serverの3つの要素で構成されます。

ClientとServer間の通信には、メッセージ形式としてJSON-RPCが使われ、通信手段としてはstdio（標準入出力）やStreamable HTTPが推奨されています。この記事では実装の簡易さからstdioが使われています。stdioによる通信とは、Serverプロセスを起動し、その標準入出力を介してメッセージをやり取りする方法です。

実装例として、ユーザーが「サイコロを振って」といったメッセージを入力すると、LLM（Host）がそのメッセージとServerが提供する機能（Tool）のリストを組み合わせて、どのTool（この場合はサイコロを振る機能）を使うべきか判断します。HostはClientを通じてServerにToolの実行を依頼し、Serverがサイコロを振った結果を返します。Hostはその結果をLLMに伝え、LLMが最終的な応答メッセージを生成してユーザーに返します。この過程では、Hostはユーザー入力に対して通常2回LLMと通信します。

ClientとServerは、初期化、操作、終了という3つのフェーズを経て通信します。

今回のスクラッチ実装は、MCPの仕組みを学ぶための最小限のものであり、エラー処理や認証などの実用的な機能は含まれていません。実際の開発では、これらの機能を含む公式のSDKを利用するのが一般的で効率的です。この記事で紹介された実装は、SDKの内部でどのような通信が行われているかを理解するのに役立ちます。

引用元: https://zenn.dev/razokulover/articles/9a0aee8ceb9f3f

この記事では、Java向けの簡単なAIコーディングエージェントをLangChain4Jというライブラリを使って作る方法が紹介されています。新人エンジニアの皆さんも、AIを使った開発がどういうものか、イメージをつかめる内容です。

作ったエージェントは、「ユーザーの指示を受けてJavaコードを生成し、ファイルに保存して実行する。もしエラーが出たら、エラーメッセージを見てコードを修正し、再び保存・実行を繰り返す」という、コード作成とデバッグの基本的な流れを自動で行うものです。

このエージェントを作る上で重要な役割を果たすのが、LangChain4Jの「Tool Calling」という機能です。これは、AIモデル（LLM）に、あらかじめ定義しておいた外部の機能（ツール）を呼び出させる仕組みです。この記事では、Javaのコードをファイルに保存するsaveCodeツールと、保存したファイルをコンパイル・実行するexecuteCodeツールを用意しています。AIは、自分で考えたコードを保存したり、実行結果を確認したりするためにこれらのツールを使います。

エージェントがどのように振る舞うかは、「システムプロンプト」というAIへの指示文で細かく設定します。「Javaコードを生成するエージェントであること」「生成したコードをsaveCodeで保存し、executeCodeで実行すること」「実行エラーが出たらコードを修正してやり直すこと」などをシステムプロンプトに記述することで、AIに目的の作業をさせることができます。

筆者は、実際にこのエージェントにJTableを使ったJavaコードを作らせて実行できた際に「おぉぉ～」と声が出たと書いており、AIがコードを書いて動かす面白さが伝わってきます。コンパイルエラーが発生しても、それをAIが自分で修正して再度実行する様子も確認できたそうです。

全体のコードはGitHubのGistで公開されています。どのようなJavaコードでツールやプロンプトを設定しているか、具体的な実装に興味があれば参照すると良いでしょう。

ただし、記事の追記として、LangChain4JのバージョンによってはTool Callingがうまく動作しないことがある（例: beta3はNG、beta2はOK）という情報も共有されており、ライブラリのバージョン選びには注意が必要な場合があることが分かります。

この記事を読むことで、LangChain4Jを使ってAIにコードを書かせ、実行させる、といった具体的なAIエージェント開発のイメージを掴むことができるでしょう。自分の手で簡単なAIツールを作ってみたいという方にとって、参考になる取り組みです。

引用元: https://nowokay.hatenablog.com/entry/2025/04/25/030248

ABEJAが、経済産業省とNEDOが進める日本の生成AI開発力強化プロジェクト「GENIAC」の一環として、新しい大規模言語モデル（LLM）であるABEJA-QwQ32b-Reasoning-Japanese-v1.0を公開しました。

このモデルの最大の特徴は、「Reasoning能力」を持っている点です。Reasoningモデルとは、回答を生成する前に、人間が考えるように一度思考プロセスを経ることで、複雑な問題や技術的な問い、推論が必要なタスクに対して、より正確で質の高い応答ができるようになるモデルのことです。

モデルは、Alibaba社が開発したQwen2.5-32B-Instructをベースに開発されました。Reasoning能力を獲得するために、同じくReasoning能力を持つQwQ-32Bというモデルの「思考に関わる部分」を、既存のモデルに賢く組み合わせる「モデルマージ」という手法が使われています。さらに、日本人ユーザーがより自然に使えるように、たくさんの日本語データを使った追加学習（SFTやDPOと呼ばれる、モデルの応答を調整する学習手法）も行われました。これにより、日本語での思考過程や回答が安定して出力されるよう性能が向上しています。

開発されたモデルの性能は、LLMの日本語能力を測るための標準的な評価方法の一つである「Japanese-MT-Bench」で評価されました。その結果、32Bというモデルサイズでありながら、GPT-4oやClaude 3.5 Sonnetといった有名な商用モデルの一部バージョンと比較しても遜色ない、高いスコアを達成しています。これは、ベースとなったモデルや、マージに使われた元のモデルよりも性能が大幅に向上していることを示しており、国産の強力なLLMとして非常に期待できる結果です。

このモデルはApache 2.0ライセンスで公開されているため、個人や企業が商用目的で自由に利用することができます。

利用する際にはいくつか注意点があります。特に、モデルの推奨するパラメータ設定（例えば、生成される文章のランダム性を調整するTemperatureやTopPなど）を使うことや、モデルの仕様に合わせた正しい入力形式（ChatTemplate）で使うことが推奨されています。システムプロンプト（AIに役割や前提条件を与える最初の指示）は、このモデルでは入れない方が性能が良いとのことです。

現時点での課題としては、思考過程が意図せず英語や中国語になる場合があること、思考プロセスが長すぎたり同じ内容を繰り返したりする場合があること、そして思考過程と最終的な回答が完全に分かれずに混ざってしまう場合があることが挙げられています。これらの課題は今後の改善で解決されていく見込みです。

ABEJAは今後もReasoning能力を持つLLMの開発を進めていく方針です。今回のモデル公開は、国内での高度な日本語LLM開発が進んでいることを示しており、エンジニアが新しいAI技術を活用する上で参考になる情報と言えるでしょう。

引用元: https://tech-blog.abeja.asia/entry/geniac2-qwen25-32b-reasoning-v1.0

この記事は、あるゲームセンターで実際にあったお客様対応の出来事とその対応について、インターネット上で様々な意見が出ていることについてまとめたものです。

内容は、お客様から「音ゲーの特定の箇所でコンボが途切れるから、筐体（ゲーム機）のメンテナンスをしてほしい」という要望があった際、担当したアルバイトスタッフが、そのお客様の目の前で実際にその箇所をプレイし、問題なくフルコンボ（連続して正しい操作を成功させること）を達成して見せた、というものです。お客様はそれを見て「もういいです」と言って立ち去られたそうです。この出来事に対し、ゲームセンターの運営者（店長と思われる）は、そのアルバイトスタッフを厳しく𠮟りつけた、というツイートが元になっています。

この店長の対応について、インターネット上では「何が悪いの？」と疑問に思う声と、「バイトの対応には問題があった」とする声に意見が分かれています。

まず、「何が悪いの？」という意見の背景には、エンジニアリングや問題解決の基本的な考え方があります。システムや機器に不具合があるという報告を受けた場合、まず最初に行うべきことは「再現確認」です。お客様が報告した現象が実際に発生するかどうかを自分たちでも試してみることで、本当に機器に問題があるのか、それとも別の要因（例えばお客様の操作ミスやゲームの仕様など）によるものなのかを切り分けることができます。今回のケースでは、お客様の「コンボが外れる」という報告に対して、アルバイトがプレイしてフルコンボできたということは、「少なくともその時点では、筐体にはコンボが外れるような不具合は見られなかった」という再現確認が取れたことになります。トラブルシューティングの観点からは、非常に真っ当で論理的なアプローチと言えます。そのため、技術的な視点を持つ人からは「なぜ正しい確認をしたのに怒られるのか分からない」という意見が多く出ています。

一方で、「バイトの対応には問題があった」という意見の背景には、顧客対応やビジネス的な視点があります。お客様は「コンボが外れる」という不具合を訴えています。その原因がたとえお客様の操作ミスだったとしても、お客様にとっては真剣な困りごとです。そのお客様の目の前で完璧なプレイを見せるという行為は、お客様に「お前の腕が悪いだけだろ」と突きつけるように見えてしまう可能性があります。これではお客様は恥ずかしく感じたり、不快な気持ちになったりして、二度と店に来なくなるかもしれません。ゲームセンターは、お客様がお金を払ってゲームをプレイしてくれることで成り立っています。技術的に正しくても、お客様の気持ちを害してしまい、結果としてお客様が離れてしまうような対応は、商売という観点からは適切ではない、という考え方です。「お客様を不快にさせないように、うまく言葉を選んだり、形だけでもメンテナンスを約束したりするべきだった」という意見が見られました。

この事例から新人エンジニアが学べることはいくつかあります。一つは、技術的な正しさや論理的なアプローチは非常に重要ですが、それだけでは全てがうまくいかない場面もあるということです。特に、お客様や他の関係者と接する際には、相手の感情や立場、求めていること（今回は「不具合を直してほしい」という技術的な要望と、「うまくプレイできない」という感情的な苛立ちの両方があったかもしれません）を理解しようと努め、コミュニケーションの方法を工夫することが求められます。トラブルシューティングの再現確認は重要ですが、それをどのように相手に伝えるか、あるいは伝えるべきでない場面もある、といった、技術以外の「立ち回り」や「配慮」も仕事を進める上で大切になる場合がある、という示唆が得られます。このケースは、技術的な正確さを追求する姿勢と、ビジネス的な顧客満足度や人間関係を重視する姿勢が対立した興味深い事例と言えるでしょう。

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

VOICEVOX:春日部つむぎ

この記事では、OpenAPIを使ったAPIスキーマ駆動開発で直面した課題と、それを解決するためにTypeSpecに移行した経験が紹介されています。

筆者のチームでは、APIの仕様を定義するのにOpenAPIのopenapi.yamlファイルを使っていました。開発を進めるにつれてこのファイルが4万行を超えるほど巨大になり、いくつかの問題が発生しました。最も大きな課題は、ファイルが大きすぎて手作業での編集が非常に大変になったこと、そしてGitHub CopilotやCursorのようなAI Agentを使う際に、ファイル全体を読み込ませようとすると情報量が多すぎて処理できなくなる（コンテキスト圧迫）ことでした。

そこで、これらの課題を解決するためにTypeSpecというAPI定義言語への移行を検討しました。TypeSpecはMicrosoftが開発しており、TypeScriptに似た分かりやすい文法でAPIの仕様を定義できます。TypeSpecで書いた定義から、OpenAPIやプログラムのクライアントコードなどを自動生成する「エミッター」という機能が強力です。

TypeSpecを選んだ理由はいくつかあります。まず、OpenAPIよりも構造化しやすく、ファイルを細かく分割して書けるため、巨大化しても管理しやすくなる点です。また、万が一TypeSpecが合わなかった場合でも、自動生成されたOpenAPIファイルを使えば元の運用に戻りやすい（撤退しやすい）ことも決め手になりました。さらに、記事執筆時点（2025年4月）でTypeSpecの安定版候補がリリースされ、安心して利用できるようになったことも後押ししました。

移行は、まずTypeSpecの環境をセットアップし、既存の4万行を超えるopenapi.yamlをTypeSpec形式に自動変換するツールを使いました。変換後、一部の型定義がうまく変換されないといった問題が発生しましたが、TypeSpecの定義を手作業で調整したり、変換ツールの挙動を一時的に修正したりして対応しました。最終的には、TypeSpecファイルからopenapi.yamlを自動生成し、これまで使っていたコード生成ツール（OpenAPI Generator）やテストツール（Committee）はそのまま使い続けられるようにしました。

移行後、TypeSpecファイルは元のOpenAPIファイルの半分以下（約2万行）になり、モデルやAPIルートごとにファイルを分割して管理できるようになりました。これにより、スキーマ全体の可読性が大幅に向上し、開発体験も改善されました。AI Agentも TypeSpec のファイルは小さく分割されているため、問題なく扱えるようになりました。また、TypeSpecを使えばOpenAPIのバージョンアップもエミッターの設定を変えるだけで簡単に行えるようになります。

TypeSpecへの移行は調整が必要な部分もありましたが、約2日間で完了し、大規模なAPIスキーマの管理や開発効率の向上、AI Agentとの連携といった多くのメリットが得られたとのことです。OpenAPIファイルの巨大化に悩んでいるチームにとって、TypeSpecは検討する価値のある選択肢と言えるでしょう。

引用元: https://zenn.dev/yuta_takahashi/articles/migrate-to-typespec

企業でAIエージェント（自律的に動くAIシステム）を活用する際、常に変化するデータに対応し、AIの精度を維持することが大きな課題となります。これを「モデルドリフト」と呼びます。例えば、顧客対応AIが参照するデータベースの形式が変わったり、ユーザーの質問の仕方が変化したりすると、AIの回答精度が落ちてしまう可能性があります。

この課題を解決し、AIエージェントの性能を継続的に向上させるための考え方が「データフライホイール」です。これは、ユーザーからのフィードバックやシステムで収集したデータを基にAIモデルを改善し、その結果AIの性能が向上することで、より多くのユーザーに使われ、さらにデータが集まる、という好循環サイクルのことです。このサイクルを回すことで、AIは常に新しいデータに適応し、精度を高く保つことができます。

データフライホイールは、特に複雑なタスクをこなすAIエージェントにとって重要です。AIエージェントは、単一の応答だけでなく、状況を判断し、複数のツールを使ったり、情報を検索したりと、多くのステップを踏んで処理を行います。そのため、計算コストが高くなりやすく、効率性が求められます。データフライホイールによってモデルを最新データで調整することで、より小さくて効率的なモデルでも高い精度を維持できるようになり、運用コスト（TCO）や応答速度（レイテンシ）の改善に繋がります。

NVIDIA NeMo Microservicesは、このデータフライホイールを実現するための包括的なプラットフォームを提供します。これは、AIエージェント開発に必要な一連のプロセスをサポートする機能群です。具体的には、AI学習のための「データ準備」、基盤となる大規模言語モデル（LLM）を特定のタスク向けに調整する「モデルカスタマイズ」（例えばLoRAのような技術を使って効率的に調整）、調整したモデルの性能を測る「モデル評価」、不適切・不正確な応答を防ぐための「ガードレール設定」、そしてモデルを実際に使えるようにする「デプロイ」といった機能がマイクロサービスとして提供されます。

例えば、AIエージェントが外部ツールを使う機能（ツール呼び出し）を改善したい場合、NeMo Microservicesを使えば、大量のツール呼び出しデータを使って効率的にモデルをファインチューニングできます。小さなモデル（例: Llama 3.2 1B）を調整するだけで、より大きなモデル（例: Llama 3.1 70B）に近いツール呼び出し精度を達成できることが示されており、大幅な効率化が可能になります。

これらのNeMo Microservicesの機能を連携させ、データ収集からモデル調整、評価、デプロイ、そして再びデータ収集へというサイクルを自動化することで、データフライホイールが構築されます。これにより、あなたの開発するAIエージェントは、常に最新の状況に適応し、性能を継続的に向上させることができます。

NeMo Microservicesは現在利用可能で、始めるためのチュートリアルやドキュメントも提供されています。まずは試してみて、AIエージェントの強化に役立ててみてください。

引用元: https://developer.nvidia.com/blog/enhance-your-ai-agent-with-data-flywheels-using-nvidia-nemo-microservices/

Webtoon Entertainmentは、「WEBTOON」や「Wattpad」といった大規模なストーリープラットフォームを運営している会社です。膨大な量のコンテンツ（マンガや小説）を扱っており、それらをマーケティング、翻訳、推薦などに活用する際に、一つ一つ手作業で内容を理解するのが大きな課題となっていました。

この課題を解決するため、Webtoonは「Webtoon Comprehension AI (WCAI)」というシステムを開発しました。これは、AIエージェントと呼ばれる「特定のタスクを実行するAI」たちが連携して働く「エージェントワークフロー」によって動いています。特に、このワークフローの構築には「LangGraph」というフレームワークが使われています。

WCAIの目的は、大量のWebtoonコンテンツに含まれるキャラクターや物語、画像とテキストの内容をAIが深く理解すること、そしてそれを効率的に（規模を拡大して）行えるようにすることです。

技術的な面では、WCAIは画像とテキストを同時に理解できるAIモデル（VLM）や、特定のタスクを実行するAIエージェントを組み合わせています。これらのAIエージェント同士を連携させ、一連の処理の流れ（ワークフロー）を作るためにLangGraphが活用されています。

なぜLangGraphを選んだのでしょうか？ それは、Webtoonの膨大なコンテンツに対応できるスケーラビリティ、マンガやストーリー特有の専門知識をワークフローに組み込める柔軟性、ビジネスで使うための高い品質と一貫性が必要だったからです。LangGraphの「ノードベース」と呼ばれる仕組みは、処理のステップを細かく分けて、それぞれに専門的な知識を適用しやすかったのです。また、エージェントの動きを細かく制御でき、デバッグや監視がしやすい点も大きな理由でした。

WCAIの中では、いくつかの主要なワークフローが動いています。例えば、「キャラクター識別」は登場人物の名前や役割、画像を特定します。「発言者識別」は、セリフが誰のものかを判断します。「物語抽出」は、ストーリーの重要な部分をテキストでまとめます。さらに、これらの情報を使って、ビジネスの目的に合わせた分析を行うワークフローもあります。例えば、マーケティングチームのために、特定のキャンペーンに合うような作品の特徴を抽出したりします。

WCAIの導入により、コンテンツの内容を手作業で確認する手間が大幅に削減されました。例えば、コンテンツチームはこれまで手作業でキーワードを抽出していましたが、WCAIを使うことで作業量が70%以上減り、よりクリエイティブな業務に集中できるようになりました。マーケティングや翻訳チームも、必要な情報を素早く得られるようになり、業務効率が向上しました。

WebtoonはこのWCAIシステムをさらに改善していく予定で、LangGraphのような新しい技術も積極的に取り入れています。この事例は、LangGraphを使ってAIエージェントによる複雑なワークフローを構築し、ビジネスの課題解決や生産性向上に繋げられることを示しています。

この内容はLangChainのブログ記事を要約したものです。

引用元: https://blog.langchain.dev/customers-webtoon/

株式会社Code and DESIGNが、対話アプリ「お喋りずんだもん」のバージョン2.0をリリースしました。このアプリは、東北応援キャラクターの「ずんだもん」とリアルタイムで自由におしゃべりできるサービスです。まるで友達と話しているかのような自然な会話を通じて、ユーザーに癒しと楽しさを提供することを目的としており、仕事や勉強の合間やリラックスしたいときなどに利用できます。

今回のバージョン2.0の大きな変更点として、アプリ内課金（In-App Purchase）に対応しました。これにより、従来の無料プランで気軽に会話を楽しめる点はそのままに、アプリをより深く楽しみたいユーザー向けにプレミアム機能が追加されています。これは、アプリのサービス提供側が、ユーザーのニーズに応えつつ、サービスを継続・発展させていくためのビジネスモデルの一つの形と言えます。

バージョン2.0は現在iOS版のみで提供されています。アプリ開発の現場では、このように特定のプラットフォームから先行して新機能をリリースするといった対応もよく行われます。

「お喋りずんだもん」は、日常にちょっとした癒しや楽しさを加えたい方にとって魅力的なアプリです。今回のアップデートは、ユーザーにとっての選択肢を増やし、アプリを継続的に運営していく上で重要な機能追加と言えるでしょう。エンジニアの視点から見ると、このような機能アップデートや課金モデルの導入は、サービス開発・運用における一般的なステップの一つとして学ぶことができます。

引用元: https://www.atpress.ne.jp/news/434030

VOICEVOX:ずんだもん

この記事は、AI AgentであるCursorを活用したWebフロントエンド開発の具体的な進め方とノウハウを紹介しています。特に新人エンジニアの方にも分かりやすいように、AIとの協調作業で開発を効率的に進めるためのフローが解説されています。

筆者は、AI Agentを使った開発では、いきなりコーディングを始めるのではなく、「要求から実装用のDocumentを作成する」フェーズと「そのDocumentに基づいて開発する」フェーズを分けて進めることを推奨しています。これは、従来の開発と同様に、事前に要件や方針をしっかり固めることで手戻りを減らし、質の高い開発を目指すためです。

「要求から実装用のDocumentを作成する」フェーズはさらに3つの段階に分かれます。

これらの3つのDocumentを作成する過程で、AI Agentとの対話を通じて不明瞭な部分を解消し、開発の方向性を固めていきます。人間はAI Agentからの提案や質問に対して、状況に合わせて判断や補足を行う役割を担います。記事では、まとまった回答を効率的に入力するために、ChatGPTの音声入力を活用する具体的なTipsも紹介されています。

「実装用Documentから開発する」フェーズでは、作成したタスクDocに基づいて、タスクを一つずつAI Agentに進めてもらいます。AI Agentはタスクの内容を理解し、必要なコードを生成してくれます。生成されたコードを確認し、期待通りであればコミットに進みます。コミットは粒度やスコープを自分でコントロールするために、手動で行うことが推奨されています。

開発が終わったら、作成したDocumentはプルリクエスト（PR）の差分に含まれないように削除コミットを作成します。PR作成時には、Documentの情報を参照させながら、AI Agentにベースとなる説明文を作成してもらうことも可能です。

このフローは、AI Agentを単なるコード生成ツールとして使うのではなく、要求整理や設計方針検討といった上流工程から「協調して」進めることで、開発プロセス全体の効率化と質の向上を目指すアプローチと言えます。ゼロから大規模な要求整理を行う場合は、よりチームでの議論が必要になるなど、まだ模索中の部分もあるとのことです。

この記事で紹介されたフローは、AI Agentを開発にどう活用できるか、具体的な一歩を踏み出すための参考になるでしょう。

引用元: https://zenn.dev/kii/articles/with_ai-agent_on_2504

AI分野をリードするNVIDIAのCEO、ジェンスン・フアン氏が日本の石破総理大臣と会談し、AI技術の未来について語りました。

石破総理は、AIを活用した地方創生や、日本がAI開発しやすい環境整備への意欲を示しました。

これに対しフアン氏は、NVIDIAが創業間もない頃から日本のゲーム会社などと協力し、日本の技術力に支えられてきたことに触れました。

フアン氏は、AIの進化を波に例えて説明しました。

そして、フアン氏が特に強調したのが、この次に来る「フィジカルAI」という新しい波です。フィジカルAIとは、単にデジタルな情報だけでなく、私たちの周りにある現実の「物理世界」を理解するAIのことです。例えば、物がどう動くか、何が原因で何が起こるか、といった物理的な仕組みや法則をAIが把握できるようになります。

フアン氏は、このフィジカルAIが「日本にとって本当に重要」だと述べました。その理由として、日本が昔から得意としている「科学技術」と「産業製造（ものづくり）」という2つの分野で、フィジカルAIが大きな可能性を解き放つからです。

フィジカルAIが物理世界を理解できるようになれば、その技術は次世代のロボット開発に繋がります。現実世界で賢く、複雑な作業をこなせるロボットを生み出す力が生まれるのです。

日本だけでなく世界中で人手不足が深刻化している今、フィジカルAIとロボティクスは、社会の課題解決に欠かせないものになるだろう、とフアン氏は語りました。

まとめると、NVIDIAのCEOは、日本の技術力とものづくりの力を評価し、物理世界を理解する「フィジカルAI」という次のAIの進化において、日本が世界の中心的な役割を果たすことへの期待を示したと言えます。これからエンジニアを目指す皆さんにとっても、「物理」と「AI」が組み合わさるこの分野は、非常に注目すべき面白いテーマになりそうです。

引用元: https://japan.cnet.com/article/35232113/

PyTorch 2.7がリリースされました！これは、世界中の多くのエンジニアの貢献によって実現された、機械学習、特にAI開発をさらに効率的かつ高性能にするための様々な機能改善が含まれています。

今回のリリースで特に注目すべき点はいくつかあります。まず、新しいNVIDIA Blackwell GPUアーキテクチャとCUDA 12.8への対応が強化されました。これにより、最新の高性能ハードウェアをPyTorchで最大限に活用できるようになります。

開発効率を上げるための機能も強化されています。モデルの実行速度を向上させるtorch.compile機能に「Torch Function Modes」が追加され、torch.から始まる様々な操作の挙動をカスタマイズできるようになりました。これにより、特定のハードウェアバックエンドに合わせた最適化などがより柔軟に行えます。「Mega Cache」という機能も導入され、一度コンパイルしたモデルの一部を保存・再利用できるようになります。これにより、開発や実験のサイクルでコンパイルにかかる時間を短縮し、効率を上げることが期待できます。

最近注目されている大規模言語モデル（LLM）の開発や実行に関する機能も進化しました。「FlexAttention」は、attention計算を効率化するための機能ですが、今回のリリースではX86系CPUでのLLMの「最初のトークン処理」や「スループット向上」に向けた最適化が進められました。また、「PyTorch Native Context Parallel」は、LLMの学習などでattention計算を効率的に並列化するためのAPIを提供します。

Intel GPUのサポートも強化されました。Windows 11でのtorch.compile対応や、学習済みモデルの軽量化手法であるPT2E（Post Training Quantization Export）の性能向上、Attention計算の高速化など、Intel GPUを使う開発者にとって嬉しい改善が多く含まれています。

他にも、リスト化された複数のテンソルに対して同じ処理を効率的に適用できる「Foreach Map」や、行列計算の準備段階の処理を最適化する「Prologue Fusion」といった新しい機能が加わっています。

PyTorch 2.7は、これらの新機能や改善によって、より多様なハードウェアで、より効率的に、そしてより高性能な機械学習モデルを開発・実行するための強力なツールとなっています。これらの機能はまだ開発途中のものもありますが、ぜひ試してみて、何か発見があればコミュニティにフィードバックをお願いします。世界中のエンジニアが協力してPyTorchをより良いものにしています。

引用元: https://pytorch.org/blog/pytorch-2-7/

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

この記事は、データ分析基盤で使われる「dbt」というツールを使ったデータモデル開発において、AIエージェントを活用して多くの定型作業を自動化した事例を紹介しています。

データを使って分析やレポートを作る際、元データを使いやすい形に加工する作業が必要です。dbtは、この加工（データモデル開発）を効率的に行うための人気ツールですが、開発するデータモデルが増えると、「ファイルの置き場所や名前のルールを守る」「データのチェック（テスト）を書く」「どんなデータか説明するドキュメントを更新する」「分析ツールで使いやすくするための設定（メタデータ定義）をする」といった、定型的な作業がたくさん発生し、開発者の負担になってしまいます。もっとSQLを書くことや分析そのものといった、頭を使う本質的な作業に集中したい、というのがエンジニアの本音です。

この課題を解決するために、筆者らは「Cursor Editor」というAI搭載の開発エディタの「Agent機能」と「Project Rules」を活用しました。

Cursor EditorのAgent機能は、指示を与えるとAIがタスクをステップごとに実行してくれる機能です。Project Rulesは、プロジェクト特有の開発ルール（命名規則、コーディング規約、標準手順など）をAIに教え込むための設定です。

dbtモデル開発には通常、SQLを書く以外にも、ファイルのテンプレート作成、ローカルでの実行確認、メタデータやテストの更新、ドキュメント作成、プルリクエスト作成など、複数のステップがあります。

これらのステップをAIエージェントに任せるために、開発チームはProject Rulesを丁寧に整備しました。具体的には、以下のようなルールを定義しました。

Project Rulesを整備し、AIにプロジェクト固有のルールをしっかり教え込んだ結果、AIエージェントはプロジェクトのやり方に沿って正確にタスクを実行できるようになりました。SQLを人間が準備すれば、それ以降の多くの定型作業（テンプレート作成、実行確認、メタデータ・テスト・ドキュメント更新、プルリクエスト作成）をAIが自動で行ってくれるようになり、ほぼ人間が最終確認するだけでGitHubにプルリクエストが作成されるレベルに達したとのことです。

もちろん、AIに任せる上で工夫も必要です。例えば、複雑なタスクは最初にAIに計画だけ立てさせる、AIに必要なルール情報を明示的に伝える、そして絶対に守りたいルールは昔ながらの自動チェックツール（静的解析、自動テスト）で間違いがないか確認する、といった「AIのための安全策（ガードレール）」を設けることが重要だと感じているそうです。

この取り組みにより、開発者はSQLの設計・実装といったクリエイティブな作業に集中できるようになり、社内からは開発効率が向上したという声があがっています。データモデル開発量も増加したという定量的な成果も出ています。

まとめとして、AIエージェントはまだ完璧ではありませんが、プロジェクト固有のルール（Project Rules）を整備し、継続的に改善していくことで、開発プロセスを大幅に自動化し、生産性を向上させることが可能です。AIにどこまで任せるか、人間とAIのより良い役割分担を考えていくことが今後の課題であり楽しみでもある、と筆者は述べています。

引用元: https://zenn.dev/ubie_dev/articles/d97c5ece4660bd

この記事は、営業AIエージェント「アポドリ」を開発する過程で得られた経験や学びを共有するSpeaker Deckの資料に基づいています。新人エンジニアの皆さんにも、AIエージェント開発の現実や考え方を理解してもらうことを目指します。

「アポドリ」は、人の代わりに企業のリストをもとに顧客にアプローチし、商談のアポイントメントを獲得するAIエージェントです。具体的には、企業情報や担当者をウェブやデータベースから収集し、相手に合わせた1対1のメッセージを生成して、メールや問い合わせフォームなど多様な手段でアプローチを実行。さらに、アプローチ結果を分析して改善に繋げるという一連の営業活動を自動で行います。

開発の道のりは順調だったわけではなく、失敗と苦労の連続だったそうです。最初は人が手作業で営業活動を行い、その過程を細かくタスクに分解することから始めました。そして、分解したタスクを一つずつAIに置き換えていくという進め方です。

AIに任せた部分の精度を上げるために、AIの出力結果を人が一件ずつ確認し、必要であれば修正し、それをAIにフィードバックして学習させるという根気のいる作業を繰り返しました。この過程で、単にAIを使うだけでなく、その業務（ここでは営業）に関する深い知識、つまり「ドメイン知識」がいかに重要であるかを強く実感したとのことです。

サービスを複数社に提供するようになると、顧客ごとにAIの振る舞いを調整する必要が出てきたり、処理する量が大幅に増えたりして、新たな課題に直面します。作業負荷が増え、手作業によるオペレーションミスも起きやすくなったため、プロンプト（AIへの指示文）をシステムの外で管理できるツール（Difyなど）を使ったり、あらゆる手作業を徹底的に自動化したりすることで、これらの課題を乗り越えていきました。この自動化を進めるにつれて、AIエージェントらしいシステムになっていったそうです。

これらの経験から、もしゼロからAIエージェントを開発するなら、以下のプロセスを推奨しています。

結論として、AIを使えば魔法のように高品質なアウトプットが簡単に出せるわけではありません。AIエージェントを成功させるためには、対象となる業務のワークフローを適切に分解し、AIに緻密な指示を与え、その結果を継続的に評価・改善していく地道な取り組みが必要不可欠です。

この記事は、AIエージェントという新しい技術に興味があるものの、具体的な開発がどう進むのかイメージが湧かない新人エンジニアにとって、開発のリアルな道のりや、ぶつかるであろう課題、そしてそれをどう乗り越えるかのヒントを与えてくれる内容となっています。AIに「任せる」ことが当たり前になる未来に向けて、どのように開発を進めていくべきかを考える良いきっかけになるでしょう。

引用元: https://speakerdeck.com/ikeyatsu/ying-ye-aieziento-apodori-notukurikata-758847a3-9962-4bee-9481-97516597fc0b

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

この記事は、Amazon Bedrock AgentsとFoursquare APIを使って、ユーザーの位置情報に基づいた賢いAIエージェントを構築する方法について解説しています。

パーソナル化された体験を提供するために、ユーザーの好みだけでなく、場所や天気といった状況も考慮することが重要です。例えば、晴れた日には公園、雨の日にはカフェといった具合に、状況に合わせたおすすめができれば、ユーザーはより満足するでしょう。このような位置情報を考慮したレコメンデーションを実現するために、Amazon Bedrock AgentsとFoursquare APIを連携させるアプローチが紹介されています。

Amazon Bedrockは、様々な高性能なAIモデルをAPI経由で利用できるAWSのサービスです。インフラ管理なしに生成AIアプリケーションを開発できます。

一方、Foursquare Places APIは、正確な位置情報インテリジェンスを提供する外部サービスです。GeoTagging APIで緯度経度から場所を特定したり、Place Search & Data APIで場所のカテゴリや属性、営業時間などで絞り込んで検索したりできます。写真やレビュー、人気度といった詳細な情報も取得可能です。

これらの技術を組み合わせることで、ユーザーが今いる場所や天気といったコンテキストを理解し、それに合わせた関連性の高い、タイムリーな情報を提供できるAIエージェントを作ることができます。記事では、Amazon Bedrock AgentがFoursquare APIと天気APIを呼び出すアーキテクチャが示されており、ユーザーが近くの公園を探したり、公園周辺のテイクアウト可能なレストランを探したりするデモ例が紹介されています。

この位置情報認識エージェントを構築するためのソースコードはGitHubリポジトリで公開されており、必要な環境変数を設定し、依存関係をインストールすれば試すことができます。

開発のベストプラクティスとしては、テストデータセットを用意してエージェントの応答を検証することや、Amazon Bedrock Guardrailsを使って不適切な入力を防ぐ対策を行うことが推奨されています。

このように、Amazon Bedrock Agentsと外部APIを連携させることで、ユーザーの状況に応じたパーソナルな応答ができるAIエージェントを構築し、より優れたユーザー体験を提供できる可能性が示されています。

引用元: https://aws.amazon.com/blogs/machine-learning/build-a-location-aware-agent-using-amazon-bedrock-agents-and-foursquare-apis/

この記事は、LLM（大規模言語モデル）をインターネット上のクラウドサービスではなく、自分のPCやスマホといった「ローカル環境」で動かす技術の現状と、まだ実用化に向けた課題について解説しています。

なぜ、わざわざLLMをローカルで動かしたいのでしょうか？その主な理由はいくつかあります。一つはコストの削減です。クラウドでLLMを使うと利用料がかかりますが、ローカルなら追加費用は不要です。次にプライバシーの向上です。機密性の高い情報を外部のサーバーに送らずに処理できるため、情報漏洩のリスクを減らせます。また、処理速度の向上も期待できます。ネットワークの遅延がないため、特に最初の応答が速くなる可能性があります。さらに、オフラインでも利用できるようになる点も大きなメリットです。例えば、スマートフォンの顔認証機能はローカルでの画像処理（推論）の良い例で、高速性、オフライン性、プライバシーが重要だからこそローカルで行われています。

この記事の著者は、Macbook Pro（M2チップ搭載）を使って、いくつか代表的なローカル推論のためのフレームワーク（プログラムの枠組み）を試しています。具体的には、C/C++で書かれた高速なllama.cpp、それを使いやすくしたOllama、そしてブラウザ上で動くWebLLMです。これらを使って、量子化（モデルを軽量化する技術）された比較的小さな（7Bサイズの）LLMを動かし、性能を測りました。クラウドのOpenAIの小さなモデルとも比較しています。

性能評価では、「最初の単語が出てくるまでの時間（TTFT）」と「1秒間に生成できる単語数（TPS）」を計測しました。結果として、llama.cppとOllamaはTTFTが非常に速く、応答までの待機時間が短いことが分かりました。TPSもこの2つは同程度でした。WebLLMはどちらの指標でも他のフレームワークより遅めでした。クラウドのOpenAIモデルと比較すると、ローカルで動かした小型モデルはTPSで劣る結果でしたが、それでも実用的なレベルの速度は出ていました。

しかし、性能面以外に、ローカルLLMにはまだ開発者が取り組むべき課題があります。最も大きな課題は、モデルの選定と配布です。ローカル環境のリソース（メモリや計算能力）は限られているため、使うタスクに最適な、小さく効率化されたモデルを見つける必要があります。ところが、世の中にはたくさんのモデルがあり、どれを選べば良いか迷いやすいのが現状です。また、選んだモデルのファイルサイズが大きい（数GB以上）ことが多く、ユーザーがアプリを使い始める前にモデルをダウンロード・ロードするのに数分かかることもあります。これは、ユーザーにとって不便で、アプリの最初の体験を損なってしまいます。

結論として、ローカルLLM推論は技術的には可能になり、性能も上がってきていますが、実用的なアプリケーションとして広く普及するには、開発者が目的のモデルを簡単に見つけ、ユーザーがモデルのダウンロードや実行を意識せずに済むような、もっと使いやすい開発ツールや配布の仕組みが必要だと筆者は述べています。将来的には、クラウドとローカルのLLMがうまく連携し、それぞれの利点を活かす形での普及が期待されます。

（992文字）

引用元: https://medium.com/@aazo11/local-llm-inference-897a06cc17a2

この記事は、128GBもの大容量メモリを搭載したM4 Max MacBook Proを使って、Googleの最新オープンな大規模言語モデル（LLM）「Gemma 3」を自分のPC（ローカル環境）で動かしてみた体験談です。API利用料やプライバシーを気にせず、手元でAIを自由に動かしたいという思いから、高性能なMacBook Proを購入し、Gemma 3のローカル実行に挑戦しています。

Gemma 3はテキストだけでなく画像なども扱える「マルチモーダル」に対応しており、特に大きな特徴は非常に長い文脈（コンテキストウィンドウ）を扱えることです。この記事では、Gemma 3の中でもサイズの異なる12B（120億パラメータ）モデルと最大の27B（270億パラメータ）モデルを試しています。

ローカルで動かすための準備は、Open WebUIやllama.cppベースのツールを使えば比較的簡単だったとのこと。M4 Maxチップと128GBメモリ、そしてAppleのMetal技術を使うことで、27Bのような大きなモデルも実用的な速度で動かせました。

実際に試したところ、面白い発見がありました。まず、夏目漱石の小説『吾輩は猫である』の要約をGemma3-12Bにお願いしたところ、内容はそれなりでしたが、なんと作者を芥川龍之介と間違えてしまいました。これは「ハルシネーション（AIが事実と異なることを生成すること）」と呼ばれる現象で、比較的小さなモデルでは知識や理解が不十分な場合があることを示しています。

次に、同じタスクをより大きなGemma3-27Bで試したところ、今度は正確な要約が返ってきました。この体験から、モデルサイズが大きいほど性能が向上することを実感できたそうです。27Bモデルは日本語の長文処理も安定しており、文脈をしっかり保ってくれます。

また、Gemma3-27Bの最大128kトークンという長いコンテキストウィンドウのすごさも体験しました。1万字を超える短編小説を丸ごと入力してテーマを尋ねたところ、全体の構造を理解した深い回答が得られ、まるでPC上で膨大な情報を扱えるAIがいるかのようだと感じたそうです。これは、たくさんのドキュメントを読ませて要約させたり、大量のコードを解析させたりといった、ローカルでの開発作業にも役立つ可能性を示しています。

さらに、Gemma 3の画像認識能力も試しました。画像を入力してその説明を求めたところ、実用レベルの応答があり、ローカルで画像も扱えるマルチモーダルAIの可能性を感じました。ただし、ローカルで画像を使う場合は、モデルを起動するディレクトリに画像ファイルを置くといった少し注意すべき点もあったようです。

高性能なMacBook Proについて、筆者は512GBメモリ搭載のMac Studio (M3 Ultra) も話題になっていることに触れつつ、数千億パラメータのような超巨大モデルを一台のPCで動かすのは計算能力的に現実的ではないと述べています。Gemma3-27Bくらいのモデルが、現在のPCで動かすには性能と負荷のバランスが良い「現実的な上限」だと考えているようです。

最後に、M4 Max MacBook Pro (128GB) は高価ではあるものの、開発作業だけでなく巨大LLMも動かせるその汎用性と性能は価格に見合う価値があり、特にApple Siliconの「ユニファイドメモリ」（CPUとGPUでメモリを共有する仕組み）が大容量を実現している点を評価しています。API料金やプライバシーを気にせずローカルでAIを試せる安心感は大きく、AI活用を本気でやりたいエンジニアにとって、メモリをたくさん積んだMacは有力な選択肢だと結んでいます。

この記事は、高性能なPCとオープンなLLMを使うことで、手元で高度なAI環境を構築できる時代が来ていることを示唆しており、ローカルAIの世界に興味があるエンジニアへの刺激となる内容です。

引用元: https://note.com/cor_instrument/n/n6d2bc4db9175

慶應義塾大学の授業で、PDF資料に一風変わったAI対策が施されていたと話題になっています。これは、学生が課題を提出する際に安易に生成AIに頼りすぎることを防ぎ、AIの特性や限界を理解してもらうための教育的な工夫として注目されています。

具体的には、配布されたPDF資料に、人間が見ても分からないように透明度100%（完全に透明）にしたテキストが大量に埋め込まれていました。この隠されたテキストには、本来の授業内容とは全く関係のない情報や、AIが誤った要約をするように誘導するような内容が含まれていたようです。

生成AIの多くは、PDFなどのドキュメントを読み込む際に、テキストデータとして処理します。このとき、文字の色や透明度といった見た目の情報は考慮されず、そこに書かれているテキストそのものを抽出してしまいます。そのため、AIにこのPDFを読み込ませて要約させると、透明で見えないはずの無関係なテキストまで含めて処理してしまい、元の内容とは全く異なる、おかしな要約結果が出てしまうという仕組みです。

この対策の面白い点は、単に「生成AIを使うな」と禁止するのではなく、AIを課題作成に利用した場合にどのような問題が起こりうるかを、学生自身に体験させる形になっていることです。「課題は自分なりの言葉で記述する」という指示と組み合わせることで、AIが生成した答えをそのまま提出しても適切な評価が得られないことを示唆し、AIの出力内容を鵜呑みにせず、自分で検証し、適切に利用することの重要性を教えています。

この事例は、AIがどのように情報を読み取るか、そしてその特性を理解した上でどのように付き合っていくべきかという、エンジニアにとっても非常に重要な学びを示唆しています。最新技術であるAIも万能ではなく、その動作原理を知り、限界を踏まえて賢く活用していく姿勢が求められていると言えるでしょう。

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

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