Episodes
-
関連リンク Claude Skills でエージェントに専門的なタスクを実行させる
Anthropic社から新たに発表された「Claude Skills」は、大規模言語モデル（LLM）であるClaudeに、特定の専門的なタスクを実行させるための強力な新機能です。新人エンジニアの皆さんも、これからのAI開発で活用できる可能性を秘めています。
これまでのClaudeでは、単に指示を理解して文章を生成するだけでなく、スプレッドシート作成のような定型的な作業も可能でしたが、Skills機能を使うと、さらに複雑で具体的なタスクを自動でこなせるようになります。例えば、「ウェブページのスクリーンショットを撮ってPDFにまとめる」といった、複数のステップを伴う処理をClaude自身に実行させることができます。
Skillsの大きな特徴は、Code Execution Tool（コード実行ツール）と連携している点です。これにより、JavaScriptやPythonといったプログラミング言語で書かれたコードをClaudeがサンドボックス環境で実行できるようになります。これは、通常のチャットだけでは実現できない高度な処理をAIエージェントに任せられることを意味します。
スキルを作成する際は、SKILL.mdというMarkdownファイルが中心となります。このファイルには、スキルの名前（name）と詳細な説明（description）を記述します。特に重要なのは、Claudeがいつそのスキルを使うべきかを判断するために、nameとdescriptionがシステムプロンプトに読み込まれることです。この設計は、必要な時だけ詳細な情報を読み込むことで、AIが一度に処理できる情報量（コンテキストウィンドウ）の圧迫を防ぎ、Claudeの性能低下を防ぐ工夫がされています。もしスキルの説明が長くなる場合は、SKILL.mdの本文は簡潔にし、詳細なコード例やヘルパースクリプトは別のファイルに分けて参照することが推奨されています。
作成したスキルは、ZIPファイルに圧縮してClaudeアプリの設定画面から簡単にアップロードできます。アップロード後、チャットで具体的なタスクを指示すると、Claudeがアップロードされたスキルの中から最適なものを選び、コードを実行して作業を進めてくれます。記事の例では、ウェブページのスクリーンショットを撮り、それらをPDFに変換するスキルを作成し、実際にClaudeにそのタスクを指示しています。
この機能は、AIエージェントがより自律的に、かつ高度な作業をこなせるようになるための重要な一歩と言えるでしょう。ただし、コードを実行するという特性上、セキュリティには十分注意し、信頼できるコードのみを使用することが肝要です。Claude Skillsは、AIの可能性を広げ、エンジニアの業務効率化に貢献する新しいツールとして注目されています。
引用元: https://azukiazusa.dev/blog/claude-skills-custom-skills-for-claude/
Spec Kit で SRE AI Agent を開発する長い旅の始まりこの記事は、SRE（Site Reliability Engineering）業務を自律型AIで自動化・半自動化する「SRE AI Agent」の開発プロジェクトについて、GitHubが提供する「Spec Kit」と「スペック駆動開発（SDD）」を活用する実践例を紹介しています。著者は「No human labor is no human error（人間が関わらなければ人間のミスは起きない）」をミッションに掲げ、AIによるSRE業務の自動化とSREチームの負担軽減を目指しています。
Spec KitとSDDは、従来のソフトウェア開発の考え方を大きく変えるものです。これまでは「コードが王様」で仕様は補助的な役割でしたが、SDDでは「仕様が王様」となります。詳細な仕様をAIに与えることで、AIが直接コードを生成し、実装まで一貫して支援してくれる新しい開発アプローチです。これにより、仕様と実際のコードの間に生じるギャップを減らし、開発の品質と効率を高めることを目指します。
Spec Kitを使った開発は、以下のようなステップで進みます。まず、プロジェクトの原則をAIと共に確立します。次に、技術的な詳細を避けつつ「何を（What）」作りたいのか、「なぜ（Why）」それが必要なのかという「仕様」をAIに記述させます。この際、大規模言語モデル（LLM）の特性を考慮し、一度に全て決めず、小さな部品ごとに定義し段階的に進めるのがポイントです。
仕様が決まったら、今度は「どのように（How）」実装するかという「技術実装計画」をAIに作成させます。ここではPythonのバージョンやAWSの構成など、具体的な技術要素を指定します。さらに、この計画を基に、より細かな「タスク」へとブレイクダウンします。
そして「実装」です。AIエージェントにタスクごとにコードを生成させ、一つ一つのタスクを完了させていきます。ここで重要なのは、人間が直接コードを修正しないというSDDの原則です。もしコードに修正が必要な場合は、まず「仕様」を修正し、その修正された仕様に基づいてAIに新たなタスクを作成させ、再実装を進めます。
また、Spec Kitには、仕様、計画、タスクの整合性を分析する機能や、要件の品質を保証するためのカスタムチェックリストを生成する機能もあります。これにより、開発の早い段階で問題を発見し、解決に導くことができます。
著者は、SDDとLLMの組み合わせが、開発における迷走や手戻りを減らし、システム開発の新たな選択肢の一つになると期待しています。AIの能力向上、ソフトウェアの複雑化、要件変化の高速化に対応する手段として、このアプローチが注目されています。新人エンジニアの皆さんにとって、AIが開発プロセス全体を支援する未来を垣間見ることができる、興味深い取り組みと言えるでしょう。
引用元: https://zenn.dev/ryoyoshii/articles/053ebb9b4cdc58
Why Your AI Agents Need a Todo ListAIエージェントの開発で、「エージェントが途中で迷子になる」「同じことを繰り返す」「まだ終わっていないのに完了したと主張する」といった壁にぶつかったことはありませんか？これは、AIの賢さが足りないのではなく、エージェントの設計（アーキテクチャ）に問題があることが多いと、この記事は指摘しています。
解決策として提案されているのは、「タスク駆動型アーキテクチャ」です。これは、AIエージェントに私たちエンジニアが使うような「Todoリスト」を強制的に持たせるという考え方です。
なぜTodoリストが重要なのでしょうか？私たち人間も、漠然とした指示ではうまく動けませんよね。「これを作って」というだけでは、何から手をつけて、どこまでやれば終わりなのかが曖昧になりがちです。AIエージェントも同じで、明確なタスクリスト、それぞれのタスクの「完了基準」、そして「完了したことの検証」がなければ、効率的かつ正確に作業を進められないのです。
タスク駆動型アーキテクチャでは、具体的に次のように進めます。
明示的なTodoリスト: エージェントは、各タスクの「内容」「完了検証方法」「完了状況」を記したリストを受け取ります。 厳格な実行ループ: エージェントはリストの未完了タスクを一つずつ実行します。 証拠に基づく検証: タスクが完了したら、その証拠（例：コードが動いた証拠、ログなど）を提示し、システムがそれを検証します。 完了するまで次へ進めない: 全てのタスクが検証済みになるまで、エージェントは次のフェーズに進むことができません。これにより、未完了のまま「終わった」と主張するのを防ぎます。このアプローチは、AIエージェントが「何をすべきか」「どこまで進んだか」を常に確認できる「外部記憶」の役割を果たし、指示が曖昧なことで起こる問題を解決します。
実際にこの仕組みを導入した経験から、以下の点が重要だと述べています。
AIの「思考の柔軟さ（温度設定）」をタスクに合わせて変える: 確実に動かすインフラ系のタスクは柔軟性を低く（例：0.0）、アイデア出しのようなクリエイティブなタスクは柔軟性を高く（例：0.5）設定します。 明確な完了基準: 「ログインページを作る」ではなく、「ユーザー名/パスワード入力欄があり、送信ボタンを押すと/api/auth/loginにリクエストを送り、JWTをコンソールに出力するログインページを作る」のように具体的に定義します。 進捗の監視: 完了率やエラー頻度などを追跡し、データに基づいて改善します。 タスクの細分化: 大きなタスクは細かく分割し、明確なステップにします。 完了には「証拠」を求める: 「終わった」と信じるのではなく、「UIが動いているスクリーンショット」や「APIレスポンスのcurl出力」などの証拠を求めます。 専門家エージェントに分ける: 全てをこなす万能エージェントではなく、「要件分析」「UI設計」「バックエンド実装」のように役割を分け、連携させることで、複雑な問題を効率的に解決します。タスク駆動型アーキテクチャは、最新のLLMを使うこと以上に、堅牢で信頼性の高いAIエージェントを開発するための土台となります。これにより、エージェントは信頼性が高く、デバッグしやすく、ユーザーから信頼され、スケールしやすいものになります。新人エンジニアの皆さんも、AIエージェントを設計する際は、まずはこの「Todoリスト」のアプローチを検討してみてください。
引用元: https://blog.justcopy.ai/p/why-your-ai-agents-need-a-todo-list
YouTubeに突如現れた「じゃんけん女子高生」…なんとアニメーターの渡辺明夫氏が描いていた！本人に当時のことを直撃してみたYouTubeで突如バズった約30年前のアーケードゲーム「じゃんけん女子高生」。その可愛いキャラクターは、人気アニメーターの渡辺明夫さんがデザインしていました。渡辺さんへのインタビューで、女子高生は初心者向けサブキャラで、実は猫や舞妓さんがメインだったこと、特徴的な鼻の穴へのこだわりなどが明かされました。当時は規制でほとんど世に出なかった幻のゲームが今注目され、「恥ずかしいが、実績を見てもらえて嬉しい」と、当時の想いを語っています。
引用元: https://www.gamespark.jp/article/2025/10/26/158774.html
お便り投稿フォームVOICEVOX:春日部つむぎ
-
youtube版(スライド付き)関連リンク OpenAI acquires Software Applications Incorporated, maker of Sky
皆さん、こんにちは！今回はAI業界で注目すべきニュースがあります。ChatGPTの開発元であるOpenAIが、macOS向けのAIインターフェース「Sky」を開発しているSoftware Applications Incorporatedという企業を買収したと発表しました。新人エンジニアの皆さんにとっては、AIが今後どのように私たちの仕事や日常に深く関わってくるかを知る上で、とても重要な動向なので、ぜひチェックしてください。
SkyってどんなAIなの？Skyは、Macのパソコン上で動作する、賢いAIアシスタントです。一般的なAIチャットボットとは少し異なり、画面に表示されている内容を理解し、さらに様々なアプリ（例えば、ドキュメント作成ソフトやカレンダーアプリなど）をあなたの指示に従って操作できるのが大きな特徴です。例えば、あなたが文書を作成している時に「この段落を要約して」と指示したり、会議の予定を口頭で伝えたりするだけで、Skyがあなたの意図を汲み取り、代わりに作業を進めてくれるイメージです。まるで、いつもあなたの作業をサポートしてくれる優秀な秘書がパソコンの中にいるようなものですね。
OpenAIが買収した理由OpenAIは、AIの能力を単に質問に答えるだけでなく、もっと実用的に、そしてシームレスに人々の生活や仕事に役立てたいと考えています。今回のSky買収は、このビジョンを大きく加速させるための一歩です。OpenAIは、Skyが持つmacOSへの深い統合技術や、ユーザーにとって使いやすい製品を作り上げるノウハウを、自社の主力製品であるChatGPTに組み込んでいく予定です。
これにより、将来的にはChatGPTが、私たちがパソコンで行うあらゆる作業において、より自然で直感的な形でサポートしてくれるようになるでしょう。例えば、プログラミング中にコードの改善案を提示したり、プレゼンテーション資料の作成を手伝ったりと、AIが私たちの「相棒」のように機能する未来が近づいています。
このニュースが示す未来これまでのAIは、特定のウェブサイトやアプリ内で利用されることが多かったかもしれません。しかし、今回の買収は、AIがパソコンのOSレベル、つまりシステムの根幹にまで統合され、私たちの作業をより深く、そして広範囲に支援する時代が来ることを明確に示しています。
OpenAIの担当者も「ChatGPTが単にプロンプトに反応するだけでなく、実際に物事を達成する手助けをする未来を築いている」と語っています。Skyの開発者も「AIがデスクトップ上で思考や創造を助ける」というビジョンを掲げており、両社の目指す方向性が一致しています。
この動きは、AIが私たちに代わって複雑なタスクを実行する「AIエージェント」へと進化していくことを示唆しています。私たちエンジニアも、このようなAIの進化に常にアンテナを張り、どのようにAIを活用し、そしてAIと共に新しい価値を創造していくかを考えることが、これからのキャリアにおいて非常に重要になるでしょう。
引用元: https://openai.com/index/openai-acquires-software-applications-incorporated
Building the Open Agent Ecosystem Together: Introducing OpenEnvHugging FaceとMetaは、AIエージェントの開発を加速させるため、新しいオープンなエコシステム「OpenEnv」と、そのためのコミュニティハブを共同で立ち上げました。これは、AIエージェントがより安全かつ効率的に多様なタスクを実行するための重要な取り組みです。
現代のAIエージェントは非常に賢く、多くのタスクを自律的にこなせます。しかし、実際にこれらのタスクを実行させるには、エージェントがプログラムやAPIといった「ツール」にアクセスできる必要があります。問題は、無数のツールを直接AIモデルに与えると、管理が複雑になり、セキュリティ上のリスクも高まる点です。
この課題を解決するために導入されたのが「エージェント環境（Agentic Environments）」という概念です。エージェント環境とは、AIエージェントが特定のタスクをこなすために「本当に必要なものだけ」を定義する、安全で明確なサンドボックス（隔離された実行空間）のことです。これにより、エージェントがアクセスできる範囲が明確になり、セキュリティを保ちつつ、必要なツールへのスムーズなアクセスが可能になります。トレーニングでもデプロイメントでも利用でき、エージェントの行動を予測しやすくします。
Hugging Face上に開設された「OpenEnv Hub」は、開発者がこのエージェント環境を構築したり、他の開発者と共有したり、探索したりできる場所です。OpenEnvの仕様に準拠した環境は、このハブにアップロードすることで、エージェントがその環境内でどのように振る舞うかを簡単に検証できるようになります。
この取り組みでは、「RFCs（Request for Comments）」という形でコミュニティからのフィードバックを積極的に取り入れ、環境作成のための標準的なAPIを定義しています。これにより、エージェントの強化学習（RL）のトレーニング、最新の研究成果の再現、そして開発から本番環境へのデプロイまで、一貫したエージェント開発のパイプラインを構築できるようになります。
OpenEnvは、MetaのTorchForge RLライブラリをはじめ、TRLやSkyRLなどの他のオープンソースRLプロジェクトとも連携を強化していく予定です。このオープンな協力体制を通じて、AIエージェントの開発がよりアクセスしやすく、スケールしやすいものになることを目指しています。新人エンジニアの皆さんも、ぜひこの新しいオープンなエコシステムに注目し、未来のエージェント開発に参加してみてはいかがでしょうか。
引用元: https://huggingface.co/blog/openenv
【Copilot最新機能】Excelの日常業務はこう変わる、一線を越えた「Agent Mode」の衝撃Microsoft 365 Copilotに、仕事のやり方を大きく変える二つの新機能「Agent Mode」と「Office Agent」が登場しました。これは、AIが単なるアシスタントの役割を超え、より自律的に業務を遂行する「Agent（エージェント）」へと進化することを意味します。特に、この進化によってExcelやWordといった日常的に使うツールの操作方法が、「手順を覚える」ことから「目的を伝える」ことへと大きくシフトします。
新しい働き方は「Vibe Working」と名付けられ、AIとの対話を通じて、より効率的に仕事を進めることを目指しています。
具体的な新機能は以下の通りです。
Agent Mode: ExcelやWordに組み込まれる機能で、ユーザーが「何をしたいか」を伝えるだけで、AIがそのタスクを計画・実行・検証・修正まで自律的に行います。例えば、Excelでのデータ整理や分析など、複数ステップにわたる複雑な作業も、AIが代行してくれるようになります。これにより、私たちが一つ一つの手順を細かく指示する必要がなくなり、より本質的な業務に集中できるようになります。 Office Agent: Copilotチャットを通じて、WordやPowerPointのドキュメント作成をAIに一任できる機能です。Webでの情報収集から、資料の構成案作成、デザイン、そして品質チェックに至るまで、一連の作業をAIがワンストップでこなします。技術的な側面では、「Office Agent」にAnthropic社の高性能AIモデル「Claude」が採用され、CopilotはOpenAIのモデルを継続利用するという「マルチモデル戦略」が始動しました。これは、用途に応じて最適なAIモデルを使い分けることで、より高品質な成果を生み出すことを目指しています。
新人エンジニアの皆さんにとって、これらの機能は日常業務の生産性を劇的に向上させる大きなチャンスです。AIが自律的に動くようになることで、私たちは「どう操作するか」よりも「AIに何をさせたいか」という“問いかけの力”が重要になります。新しい技術の動向にアンテナを張り、AIを強力なパートナーとして活用するスキルを身につけることが、これからのエンジニアにとって不可欠となるでしょう。
引用元: https://www.sbbit.jp/article/cont1/173554
ポムポムプリン公式アカウントの“おさわりマップ”公開がきっかけとなり飼っている犬や猫のおさわりマップ投稿が大流行、見た目とのギャップがかわいらしいポムポムプリン公式が公開した「おさわりマップ」がきっかけで、X（旧Twitter）では飼っている犬や猫の「おさわりマップ」を投稿するブームが起きています。これは、ペットのどこを触ると喜ぶか、どこが嫌かなどをイラストでまとめたもの。全身ウェルカムな子や、特定の場所だけを許す子など、見た目と性格のギャップが面白く、動物たちの個性豊かな反応に多くの人が癒やされ、心温まる交流を楽しんでいます。
引用元: https://togetter.com/li/2619204
お便り投稿フォームVOICEVOX:ずんだもん
-
Missing episodes?
-
youtube版(スライド付き)関連リンク Introducing ChatGPT Atlas
OpenAIは、ChatGPTをウェブブラウザの中心に据えた新しいツール「ChatGPT Atlas」を発表しました。これは、AIを活用してインターネットの利用体験を根本的に見直し、あなたの強力な「スーパーアシスタント」として機能することを目指しています。
Atlasの主な特徴は、ChatGPTがウェブページの内容をリアルタイムで理解し、あなたの作業を直接サポートしてくれる点です。例えば、オンライン上の資料を見ながら疑問が生じた際に、その場でChatGPTに質問でき、コピー＆ペーストの手間なく回答を得られます。
さらに、「ブラウザ記憶（Browser memories）」という機能により、あなたが以前閲覧したウェブページの情報をChatGPTが記憶し、それを踏まえた上で質問に答えたり、タスクを処理したりできます。「先週見た求人情報をすべてまとめて、面接対策用の業界トレンドの要約を作成してほしい」といった高度な依頼にも対応可能です。この記憶機能は任意で、ユーザーがいつでも内容を確認・管理・削除できるため、プライバシーは確保されています。
もう一つの重要な機能は「エージェントモード」です。これは、ChatGPTがあなたの指示に基づいてウェブ上で具体的なアクションを実行してくれるものです。例えば、レシピを伝えればオンラインストアで必要な食材を検索し、注文まで代行できます。ビジネスシーンでは、チーム資料の分析や競合調査、その結果の要約なども自動で行えます。このエージェントモードは、現在Plus、Pro、Businessユーザー向けにプレビュー提供中です。
OpenAIはプライバシーとセキュリティにも力を入れています。Atlasでは、ChatGPTがアクセスできる情報や記憶する内容をユーザーが細かく設定できます。シークレットモードや、特定のサイトでChatGPTのページ内容へのアクセスを制限する機能も備わっています。また、あなたの閲覧情報がChatGPTのモデル学習に使われることは、あなたが明示的に許可しない限りありません。エージェント機能についても、コード実行やファイルのダウンロードはできないよう設計されており、金融機関のような機密性の高いサイトでは、アクション実行前にユーザーの確認を求めるなど、安全対策が施されています。ただし、AIエージェントの利用には、誤作動や悪意ある指示によるリスクも存在するため、注意して利用することが推奨されています。
ChatGPT AtlasはmacOS向けに本日より提供が開始され、Windows、iOS、Android版も近日中にリリース予定です。この新しいブラウザは、AIが日々のウェブ利用をより効率的でパーソナルなものに変え、私たちの生産性を向上させる未来への大きな一歩となるでしょう。
引用元: https://openai.com/index/introducing-chatgpt-atlas
Create Your Own Bash Computer Use Agent with NVIDIA Nemotron in One Hourこの記事では、NVIDIAの高性能な小型AIモデル「Nemotron Nano v2」を使って、自然言語でBashコマンドを操作できるAIエージェントを、わずか1時間、約200行のPythonコードで作成する方法が紹介されています。新人エンジニアの皆さんにとって、AIエージェント開発の第一歩として非常にわかりやすい内容です。
従来のチャットボットが質問応答に特化しているのに対し、AIエージェントは「ツール呼び出し」という機能を使って、高レベルな目標を自律的に判断し、計画し、タスクを実行します。今回のエージェントは、皆さんが普段使っているBashターミナルを「ツール」として利用し、「システム情報をまとめて」といった指示に対して、適切なコマンド（mkdir, df, free, catなど）を自動で実行し、結果を要約してくれます。
このエージェントを開発する上で重要なポイントがいくつかあります。
Bashの操作: エージェントがBashコマンドを実行し、その結果を受け取るための仕組みが必要です。作業ディレクトリの管理も大切です。 コマンドの安全性: 誤って危険なコマンドを実行しないよう、「許可されたコマンドリスト」を設定し、実行前にはユーザーの承認を求める「ヒューマン・イン・ザ・ループ」の仕組みを取り入れます。これにより、安全にエージェントを試すことができます。 エラーハンドリング: コマンド実行時のエラー（間違ったコマンド、ファイルがないなど）をAIが理解し、次の行動を適切に判断できるようにする仕組みが重要です。システムは主に2つの要素で構成されます。
Bashクラス: Pythonのsubprocessモジュールを利用し、実際にシェルコマンドを実行する部分です。許可コマンドリストのチェックや、現在の作業ディレクトリの管理も行います。 エージェント本体: Nemotronモデルがユーザーの指示を理解し、次にどのようなBashコマンドを実行すべきか判断します。「システムプロンプト」というAIへの指示書を使って、エージェントの役割や、使えるコマンド、安全に関するルールを細かく設定します。記事では、これらのコンポーネントをゼロから構築する方法と、LangChainのライブラリである「LangGraph」を使うことで、さらにシンプルにエージェントループを構築できる方法が示されています。LangGraphを使えば、AIエージェントの複雑な状態管理やツール呼び出しの処理を簡単に実装できます。
このチュートリアルを通して、AIエージェントがどのようにユーザーの意図を理解し、外部ツール（Bash）と連携してタスクを自律的に実行するかの基本原理を学ぶことができます。ぜひ、ご自身でコマンドを追加したり、プロンプトを調整したりして、AIエージェントの可能性を探ってみてください。
引用元: https://developer.nvidia.com/blog/create-your-own-bash-computer-use-agent-with-nvidia-nemotron-in-one-hour/
開発合宿で Claude Codeの「サブエージェント」について学んだ話この記事では、株式会社カミナシのエンジニアが開発合宿で学んだ、Claude Codeの「サブエージェント」という機能について、新人エンジニアの方にも分かりやすく解説されています。AIを使った開発を進める上でのヒントが得られる内容です。
開発合宿では、「人間は一切コードを書かず、AIエージェントのみでシステムを開発する」という目標が設定されました。普段のAIコーディングでは、AIに適切な指示や背景情報（これを「コンテキスト」と呼びます）を与えることがとても重要です。著者のチームでは、開発ルールをまとめた「CLAUDE.md」というファイルを使ってAIに指示を出していましたが、複数のプロジェクトを一つのリポジトリで管理する「モノレポ」環境のため、このファイルがどんどん肥大化していくという課題に直面していました。
CLAUDE.mdが大きくなりすぎると、例えばAPI開発をAIに依頼したいのに、フロントエンドのコンポーネント命名規則など、API開発には不要な情報までAIに読み込ませてしまうことになります。これはAIが指示を理解するのを難しくし、開発の効率を下げてしまう可能性がありました。
この課題を解決するために、合宿でチームメンバーから教えてもらったのが「サブエージェント」という機能です。サブエージェントとは、特定のタスク（例：フロントエンド開発、API開発、データベース設計など）に必要な情報とルールだけを持たせることができる、専門特化したAIエージェントのことです。
サブエージェントを使うことで、肥大化していたCLAUDE.mdを分割し、例えばAPI開発用のサブエージェントには「TypeScriptを使う」「関数型プログラミングで実装する」「テスト駆動開発を徹底する」といった、API開発に特化した最小限のルールだけを伝えることができるようになりました。
開発合宿では、システムアーキテクチャ設計用、API開発用、フロントエンド開発用、データベース設計用など、それぞれの専門サブエージェントを作成し、実際に開発を行いました。各エージェントには、その役割に合わせたベストプラクティスや開発ルールを「プロンプト」（AIへの指示文）として学習させました。
この仕組みを取り入れた結果、メインのCLAUDE.mdはシンプルに保たれ、各タスクを専門知識を持つサブエージェントに任せることで、AIコーディングの指示出しが非常にスムーズになり、開発の効率と精度が大きく向上したとのことです。
この記事は、「AIに『すべて』を教え込むのではなく、『必要な時に、必要な情報だけ』を渡すことが、AIを使った開発を成功させる鍵である」という重要なメッセージを伝えています。AIを活用して効率的に開発を進めるための、具体的な実践例として、新人エンジニアの皆さんにも非常に参考になるでしょう。
引用元: https://kaminashi-developer.hatenablog.jp/entry/dev-camp-claude-subagents
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク やさしいClaude Skills入門
Anthropic社のAI「Claude」に、新たに「Claude Skills」という強力な機能が加わりました。これは、Claudeが特定のタスクを高品質かつ効率的に実行するための「ベストプラクティス集」のようなもので、指示やスクリプト、必要なリソースなどを一まとめにしたものです。技術的には「Agent Skills」とも呼ばれ、最近エンジニア界隈で大きな注目を集めています。
Claude Skillsの導入で嬉しいのは、AIにタスクを依頼する際の試行錯誤が減り、まるで経験豊富な先輩が手本を示すように、Claudeが最適な手順で作業を進められるようになる点です。これにより、私たちはAIの能力を最大限に引き出し、より少ない労力で高い成果を期待できるようになります。
その仕組みは、主に「SKILL.md」ファイルに記述されたスキルの概要情報（メタデータ）と、Claudeがファイルを読み込むための「Readツール」で動きます。Claudeは必要なSkillsのファイルだけを動的に読み込むため、AIが一度に扱える情報量（コンテキストウィンドウ）を無駄に消費せず、効率的な処理を実現します。これは、常にプロジェクト全体の指示を保持する「CLAUDE.md」や、ツール接続のプロトコルである「MCP」とは異なり、特定のタスクに特化した「便利機能パック」として、より具体的な作業効率化を目指しています。
Claude Skillsは、Claude Desktop、Claude API、Claude Codeなど様々な環境で利用可能です。Desktop版では設定から簡単に有効化でき、自作のSkillsもアップロードできます。API経由の場合は事前に登録が必要です。また、公式から提供されている「skill creator」というSkillsを使えば、独自のSkillsを効率的に作成できます。
効果的なSkillsを作るための「ベストプラクティス」（良いやり方）も紹介されています。特に、SKILL.mdのメタデータは常に読み込まれるため、簡潔にまとめることが重要です。また、SKILL.md自体の内容は500行以下に抑え、詳細な情報は別ファイルに分割するのが推奨されています。
具体的な活用事例としては、ウェブサービス「キミガタリ」の月間アップデートレポートを自動作成する取り組みが紹介されています。これまでは手動で行っていた定型レポート作成作業が、Claude Skillsを使うことで、現在時刻の確認から、Qiita投稿やGitコミット履歴の取得・分析、既存フォーマットへの沿った記事作成までを自動化。数秒で「まるで自分が書いたような記事」が完成するようになり、大幅な効率化が実現しました。
Claude Skillsは、ベテランエンジニアの知識やノウハウをAIに学習させ、組織における「属人化」（特定の個人にしかできない仕事）を解消する可能性を秘めています。質の高いSkillsが販売されるエコシステムの発展も期待されており、新人エンジニアの皆さんにとって、AIの活用範囲を広げる強力なツールとなるでしょう。
引用元: https://www.docswell.com/s/harinezumi/5M683X-2025-10-21-003933
LangChain raises $125M to build the platform for agent engineeringAIエージェント開発をリードするLangChainが、1.25億ドル（約180億円）の資金調達と、企業価値12.5億ドル（約1800億円）への評価を発表しました。この資金は、AIエージェントをより信頼性高く開発するための「エージェントエンジニアリング」プラットフォームの構築に充てられます。
LLM（大規模言語モデル）の登場で様々なアプリケーションが可能になりましたが、データやAPIと連携して自律的に動く「AIエージェント」こそがその真の力を引き出します。しかし、AIエージェントは試作は容易でも、本番環境で安定稼働させるのは非常に難しいという課題があります。「エージェントエンジニアリング」とは、この課題を解決し、非決定論的なLLMシステムを信頼性の高い体験へと磨き上げていく反復的なプロセスです。
LangChainはこの「エージェントエンジニアリング」のための包括的なプラットフォームを提供しています。主な発表内容は以下の通りです。
LangChainとLangGraphの1.0リリース: AIエージェントを迅速に構築できるオープンソースフレームワークが安定版となり、一般的なエージェントパターン向けのアーキテクチャが強化されました。LangGraphを使えば、エージェントの動作をより細かく制御できます。 LangSmithの機能強化: エージェントの挙動を可視化する「Observability」、生産データでテスト・評価する「Evaluation」、ワンクリックでデプロイできる「Deployment」、そしてノーコードでエージェントを構築できる「Agent Builder」（プライベートプレビュー中）が提供され、開発から運用までをトータルでサポートします。 Insights Agentの導入: LangSmithの機能として、エージェントの動作パターンを自動で分類する「Insights Agent」が追加されました。LangChainのツール群は、AIエージェント開発のハードルを下げ、開発者が信頼性の高いエージェントをより効率的に生み出すことを支援します。AIエージェントが次の大きな波となる中で、LangChainの動向は今後も注目されそうです。
引用元: https://blog.langchain.com/series-b/
LLMs Can Get Brain Rotこの研究では、大規模言語モデル（LLM）も人間のように、低品質な情報に触れ続けることで能力が低下する「LLMブレインロット（脳の腐敗）仮説」を提唱し、その実証実験を行いました。「ブレインロット」とは、インターネット上の「つまらないけれど目を引くコンテンツ」ばかりを見ていると、人間の集中力や記憶力、判断力が鈍るという俗語から着想を得た言葉です。
研究チームは、LLMが継続的に「ジャンクデータ」に触れると、モデルの認知能力が長期的に低下するという仮説を立てました。これを検証するため、実際のTwitter/Xの投稿を基に、以下の2種類の基準で「ジャンクデータ」と「コントロールデータ（通常の高品質なデータ）」を作成しました。
M1 (エンゲージメント度)：人気があって短い、いわゆる「バズった」投稿をジャンクデータとしました。これは、注意を引くが内容の浅い情報が、人間がSNSを延々と見てしまう現象に似ているためです。 M2 (意味的品質)：「すごい！」「今日だけ！」のような扇情的な言葉や誇張された表現を含む投稿をジャンクデータとしました。これらのジャンクデータをLLMに継続的に学習させたところ、驚くべき結果が明らかになりました。ジャンクデータに触れ続けたLLMは、そうでないモデルと比べて、推論能力、長文の理解力、安全性（不適切な指示への対応）が著しく低下することが判明しました。例えば、推論タスクのスコアが大幅に落ち込んだり、サイコパシーや自己愛といった「ダークな特性」を示す傾向が強まったりしました。また、ジャンクデータの割合が増えるほど、能力の低下がより顕著になるという「用量反応性」も確認されました。
エラーの原因を詳しく調べた結果、LLMが思考プロセスを途中で省略してしまう「思考スキップ」が、能力低下の主要な要因であることが分かりました。さらに懸念されるのは、一度ジャンクデータに汚染されて能力が低下したLLMは、その後、高品質なデータを使った追加学習やファインチューニングを行っても、元の能力レベルまで完全に回復することは難しいという点です。これは、モデル内部の表現に根本的な変化が生じてしまうことを示唆しています。
この研究は、LLMの学習データとしてインターネット上の情報を用いる際、そのデータ品質の重要性を改めて浮き彫りにしました。私たちがAIの信頼性や性能を維持していくためには、継続的な学習におけるデータの選定と品質管理が極めて重要であり、まるで人間の健康診断のように、展開されているLLMに対しても定期的な「認知的健康診断」が必要であると結論付けています。
引用元: https://llm-brain-rot.github.io/
「ひかれるという感情が薄い」→北海道の車道で目撃……車をまったく気にしない野生動物 釧路では「まれによくある」光景に5.2万“いいね”北海道釧路で、車道をまったく気にせず堂々と歩く野生動物の姿がSNSで5.2万いいねを集め話題になっています。この地域では動物たちが車に「ひかれる」という感情が薄く、このような光景は「まれによくある」とのこと。私たちエンジニアも、時にはコードから離れて、自然の中での面白い出来事に目を向け、クスッと笑ってリフレッシュするのも良いかもしれませんね。
引用元: https://hint-pot.jp/archives/281691/3/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク Build an AI Agent to Analyze IT Tickets with NVIDIA Nemotron
現代のIT運用では、インシデントや問い合わせから生まれる膨大なチケットデータがあります。しかし、これらのデータは単なる記録であり、そこからシステム全体の課題やチームのパフォーマンスに関する深い洞察を得るのは困難です。多くの場合、手作業での分析や複雑なクエリが必要となり、時間と労力がかかります。
NVIDIAのIT部門が開発したAIエージェント「ITelligence」は、この課題を解決するために作られました。このシステムは、NVIDIA Nemotronという先進的なAIモデルの推論能力と、データ間の関係性を明確にするグラフデータベースを組み合わせています。これにより、LLM（大規模言語モデル）で非構造化データから文脈を読み解き、グラフクエリでチケット間の関係性、異常、パターンを効率的に見つけ出すことを目指します。
AIエージェントの構築は、以下の主要なステップで行われます。
データ取り込みとグラフモデリング: ITSM（ITサービス管理）プラットフォームなどからチケットデータを収集し、ユーザー、インシデント、デバイスといった情報を「ノード」、関連性を「エッジ」としてグラフデータベースに格納。複雑なデータ間のつながりを可視化し、効率的なクエリを可能にします。 文脈のエンリッチメント: チケットに「新入社員の有無」「デバイスの種類」といった補助情報を追加し、分析の分類能力を高めます。 根本原因分析（RCA）: LLM（例: Llama 3）を使って、チケットの記述や解決メモから、具体的な根本原因キーワードを自動抽出。従来のカテゴリー分類では捉えきれない詳細な問題点を特定できます。 洞察の生成: LLMが、解決時間（MTTR）、顧客満足度（CSAT）、頻繁に発生する根本原因、新入社員のオンボーディング時の課題など、組織やチームレベルでのパターンや洞察を自動生成します。 アラートと自動配信: KPIトレンドを監視し、異常があれば担当者に自動でアラートを送信。また、AIが生成した要約レポートを定期的に自動配信し、部門ごとの具体的な情報共有と意思決定をサポートします。インターフェースには、複雑な質問に対応できるインタラクティブなダッシュボード（Grafanaなど）が採用されました。RAG（検索拡張生成）ベースのチャットボットではなくダッシュボードを選んだのは、チャットボットではユーザーの複雑な意図を正確に解釈し、常に適切なクエリを生成するのが難しい場合があるためです。代わりに、ダッシュボードのフィルタリング結果と連携するカスタムの要約サービスAPIを介して、LLMがオンデマンドで要約を生成。これにより、手動でのチケットレビューを省き、共通の問題点や推奨事項を迅速に把握できるようになります。
このAIエージェントは、非構造化されたITチケットデータを実用的な洞察に変え、IT運用の意思決定と効率化を強力に支援します。
引用元: https://developer.nvidia.com/blog/build-an-ai-agent-to-analyze-it-tickets-with-nvidia-nemotron/
Scaling Large MoE Models with Wide Expert Parallelism on NVL72 Rack Scale Systems最近のAI、特に大規模言語モデル（LLM）はますます巨大化しており、その中でも「MoE（Mixture-of-Experts）」という特殊な構造を持つモデルが注目されています。MoEモデルは、トークンごとに一部の「エキスパート」（専門家）だけを動かすことで、従来のモデルよりも効率的に計算できるのが特徴です。しかし、このMoEモデルを非常に大規模な環境で効率よく動かすには、いくつかの課題があります。
この記事では、NVIDIAが提案する「Wide Expert Parallelism（Wide-EP）」という技術と、その基盤となる「GB200 NVL72」というシステムが、これらの課題をどのように解決し、大規模MoEモデルの推論を高速化・効率化するのかを解説しています。
MoEモデルスケーリングの課題とWide-EPによる解決策
メモリと計算のボトルネック： MoEモデルでは、必要なエキスパートの「重み」（モデルの知識データ）をGPUに読み込む作業が頻繁に発生し、これが処理の遅延につながります。Wide-EPでは、エキスパートの処理を多数のGPUに分散させることで、1つのGPUが持つエキスパートの数を減らし、重みデータの読み込みを効率化します。これにより、GPUがより集中して計算に専念できるようになります。
GPU間の通信オーバーヘッド： エキスパートが複数のGPUに分散しているため、計算結果を集約する際に大量のデータ通信が必要になります。この通信が遅れると、全体の処理速度が低下します。GB200 NVL72システムは、超高速なNVLinkという技術でGPU間を接続しており、最大130TB/秒という圧倒的な帯域幅で、この通信のボトルネックを解消します。また、NVIDIAのNCCLライブラリが最適化された通信カーネルを提供し、効率的なデータ交換を可能にします。
負荷の偏り（ロードバランシング）： 特定のエキスパートが頻繁に使われる一方で、使われないエキスパートもあるため、一部のGPUばかりが忙しくなり、他のGPUが遊んでしまうことがあります。Wide-EPの「Expert Parallel Load Balancer (EPLB)」は、利用状況に応じてエキスパートのGPUへの割り当てをリアルタイムまたは事前に調整し、すべてのGPUが均等に働くように負荷を分散します。
これらの技術はNVIDIAのTensorRT-LLMに組み込まれており、さらに「NVIDIA Dynamo」と組み合わせることで、大規模なMoEモデル推論のオーケストレーション（全体の管理）と実行を最適化します。
性能と経済性へのインパクト
Wide-EPをGB200 NVL72システムで活用することで、GPUあたりの処理能力が最大1.8倍向上することが確認されています。これは、モデルの推論コスト（TCO）を大幅に削減し、より多くのユーザーに対して高速なAIサービスを提供できることを意味します。新人エンジニアの皆さんにとっては、将来、巨大なAIモデルを扱う際に、このような分散処理と最適化技術が非常に重要になるということを理解する上で、この記事は良い学びになるでしょう。
引用元: https://developer.nvidia.com/blog/scaling-large-moe-models-with-wide-expert-parallelism-on-nvl72-rack-scale-systems/
AWSで障害–PerplexityやSlackなどグローバルサービスに支障新人エンジニアの皆さん、今日の重要なITニュースについてお話しします。私たちが毎日使っているインターネットサービスは、巨大な「クラウドサービス」という基盤の上で動いていることが多いのですが、その代表格であるAmazonの「Amazon Web Services（AWS）」で、世界的な障害が発生しました。
AWSは、世界中の企業がウェブサイト、アプリケーション、データ保存、そして最近ではAIの複雑な計算処理など、様々なITシステムを動かすために利用している巨大なデータセンターの集合体です。今回の障害は、2025年10月20日17時30分頃、主にアメリカ東部の「US-EAST-1」というリージョン（物理的に離れた地域に設置された、独立したデータセンターのグループ）で発生しました。このUS-EAST-1は、AWSの中でも特に多くのサービスが利用する中心的なリージョンの一つであるため、ここで問題が起きると影響が非常に広範囲に及ぶのが特徴です。
具体的に影響を受けたサービスとしては、最新のAIチャットサービスである「Perplexity」や、多くの企業で使われているビジネスチャットツールの「Slack」の一部機能（例えば、音声会議機能のハドルなど）、ゲームプラットフォームの「EpicGames」などが挙げられています。これらのサービスが一時的に利用できなくなったり、動作が遅くなったりする事態が発生しました。この影響はアメリカだけでなく、日本のユーザーにも波及し、SNS上では「仕事で使っているSlackのハドルが使えなくて困った」「Perplexityで調べ物ができない」といった声が多数上がりました。
PerplexityのCEO、アラヴィンド・スリニヴァス氏も、自身のX（旧Twitter）アカウントで「Perplexityが現在ダウンしており、原因はAWS側の問題だ」とコメントし、復旧に向けて対応中であることを明らかにしました。AWS側も、ステータスページで問題が発生していることを公表し、原因の特定と復旧作業を進めている状況です。
今回のAWS障害は、普段当たり前のように利用しているインターネットサービスが、いかに一つの巨大なインフラに依存しているか、そして、そのインフラで障害が発生すると世界中に影響が及ぶという現実を改めて示しています。
新人エンジニアの皆さんにとって、これは非常に重要な学びの機会です。システムを設計する際には、たとえAWSのような信頼性の高いクラウドサービスを使うとしても、「障害は起こり得る」という前提で考えることが大切です。例えば、重要なデータは複数の場所にバックアップを取る、または、複数のリージョンにシステムを分散配置して、一つがダウンしても別の場所でサービスを継続できるようにする（ディザスタリカバリや高可用性の設計）といった対策が考えられます。普段から障害への備えを意識することで、いざという時にサービスを守ることができるのです。
引用元: https://japan.cnet.com/article/35239420/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク The Case for the Return of Fine-Tuning
AIの世界では、一度は主流から外れていた「ファインチューニング」という技術が、再び大きな注目を集めています。これは、既存の大規模言語モデル（LLM）を、より特定の用途やデータに合わせて微調整する技術のことです。
かつて、Transformerモデルの登場により、ファインチューニングは効率的なモデル開発手法でした。しかし、LLMが非常に巨大化すると、モデル全体を再学習する「フルファインチューニング」は莫大な計算コストと時間が必要となり、実用的ではなくなりました。その代わりに、開発者はモデルへの指示を工夫する「プロンプトエンジニアリング」や、外部情報を参照させる「RAG（Retrieval-Augmented Generation）」を活用するようになりました。これらはモデルを再学習する必要がなく、手軽に良い結果を出せたからです。
ところが、2021年にMicrosoft Researchが発表した「LoRA（Low-Rank Adaptation）」という新しい手法が状況を変えました。LoRAは、モデルのほとんどの部分を固定し、ごく一部の小さな追加部分だけを学習することで、コストを大幅に削減しつつ、フルファインチューニングと同等の性能を引き出すことを可能にしました。Hugging FaceのPEFTライブラリもLoRAの実装を容易にし、ファインチューニングのハードルを大きく下げました。
現在、ファインチューニングが再び重要視されている主な理由は以下の通りです。
技術環境の整備: GPUを利用できるクラウドサービスが増え、LoRAのような効率的な手法が手軽に実行できるようになりました。 モデルの進化安定: LLMの進化が「革命的」から「進化的」になり、ファインチューニングしたモデルが無駄になりにくくなりました。 オープンソース化: MistralやLlamaのようなオープンなLLMが増え、企業が自社のニーズに合わせてモデルをカスタマイズしやすくなりました。 プロンプトの限界: プロンプトやRAGだけでは対応しきれない、企業独自の専門用語や話し方、複雑なルールなど、よりきめ細かなカスタマイズが求められるようになったからです。Thinking Machines Labsの「Tinker」のような新しいプラットフォームは、ファインチューニングをさらに進化させています。例えば、LoRAの適用範囲を広げたり、学習率やバッチサイズといったパラメータを工夫したりすることで、より高性能なモデルを効率的に作れるよう提唱されています。現代のファインチューニングは、一つの大きなモデルを調整するだけでなく、ベースモデルと複数のLoRAアダプターを組み合わせて、用途に応じて柔軟に切り替える「モジュール式」へと進化しています。
モデルの評価にはまだ課題が残るものの、今後は運用中にフィードバックを受けて自動で学習し続ける「継続的学習」のような仕組みも期待されています。
ファインチューニングは、単なる技術的な調整を超え、企業がAIを自社のビジネスに合わせて深くカスタマイズし、独自の強みを生み出すための「戦略的な手段」として、その価値を高めています。AIをよりパーソナルに、より専門的に活用する未来において、この技術が果たす役割はますます大きくなるでしょう。
引用元: https://welovesota.com/article/the-case-for-the-return-of-fine-tuning
LLM回答精度検証でテストデータやテストケースケースをAIに作ってもらうこの記事では、LLM（大規模言語モデル）の回答精度を検証するために必要な「テストデータ」や「テストケース」を、AIと協力して効率よく作成する方法が解説されています。新人エンジニアの皆さんも、AIを上手に活用して開発作業を効率化するヒントが得られるでしょう。
まず、LLMを使った情報検索システム（例：Slackのメッセージ検索）の検証に使う「ダミーデータ」作りからスタートです。筆者は、実際のメッセージのJSONデータをAIに見本として渡し、「スレッド内のメッセージとスレッド外のメッセージを半々で100件作ってほしい」「改行や文字数のばらつきも入れてほしい」といった具体的な条件を細かく指定しました。AIはこれらの指示に応え、人間と対話しながら、より本物に近い、多様なメッセージデータを作り上げていきました。
次に、この作成したダミーデータを異なる形式に変換する作業もAIに依頼しました。例えば、読みやすいPretty JSON形式を、プログラムで扱いやすいOne-line JSONやCSV形式に変換したい場合です。筆者はAIに「JSON部分を1行にするスクリプトを作って」と指示したり、「CSV形式ならどんな形が良いか」と相談したりしました。AIは複数の変換案を提示し、筆者のフィードバック（例：「.で階層構造を表現する」）を受けて、最終的にPythonスクリプトを生成。このスクリプトを使うことで、適切な形式のデータが自動的に準備できました。
さらに、LLMの回答が正しいかを評価するための「テストケース」もAIと共に作成しました。当初、AIの提案は単純な「番号指定」のケースに偏っていました。そこで筆者は、AIに自身の提案を見直させる「critical-think」という機能を使ってみました。するとAIは、より多様な視点からのテストが必要だと自己認識し、「BigQueryについて話しているメッセージ」のような「内容ベース」の指定や、「U089VWX0YZAさんが投稿したメッセージ」のような「ユーザー名ベース」、さらには複数の条件を組み合わせた「複合条件」など、多角的なテストケースを再提案。スレッドの返信メッセージに関するテストも要望に応じて増やし、最終的にコメント付きでテスト設定ファイルに追記するまでをAIに任せました。
このように、LLMの検証に必要なテストデータやテストケースの作成において、AIは単に指示を実行するだけでなく、課題を認識し、より良い解決策を提案する強力なパートナーとなることが示されています。AIとの効果的な「壁打ち」を通じて、開発プロセス、特に検証フェーズの効率を大幅に向上させることができるという、現代のエンジニアリングにおいて重要な知見が得られるでしょう。
引用元: https://blog.shibayu36.org/entry/2025/10/15/173000
RAGでのデータ整形(改行・インデント)がLLMの回答精度に与える影響を検証した今回の記事は、AIシステムの一つであるRAG（Retrieval Augmented Generation）において、大規模言語モデル（LLM）に渡すデータの「整形方法」（例えば、JSONデータを読みやすくするために改行やインデントを入れるかどうか）が、LLMの回答精度にどう影響するのかを検証した興味深いレポートです。
筆者は自身のプロジェクトで、トークン消費を抑えるためにデータを1行のJSON形式でLLMに渡していましたが、回答精度が不安定なことがあり、整形の影響について疑問を持っていました。そこで、この疑問を解決するために実験を行ったのです。
検証では、「oneline JSON（改行なしのJSON）」「pretty JSON（改行・インデントありのJSON）」「CSV」の3種類のデータ形式を用意し、最新のLLM（gpt-5, claude-sonnet-4-5など）と少し前のモデル（gpt-4.1-mini, claude-3-7-sonnetなど）を使って、特定の情報を抽出し、SlackのURLを生成できるかを試しました。
実験の結果、次の3つの重要な発見がありました。
データ整形は精度に大きな影響を与えない: データを見やすくするために改行やインデントを入れても、LLMの回答精度は特に向上しないことが分かりました。つまり、人間が読みやすい形式が、必ずしもLLMにとっても良いとは限らないということです。 LLMの性能向上で差がなくなる: 最新の高性能なLLM（特にgpt-5）では、どのデータ形式を使ってもほぼ100%の正答率を叩き出し、整形による精度の差はほとんどありませんでした。これは、LLMが賢くなればなるほど、データの見た目はそれほど気にしなくてよくなることを示唆しています。 トークン効率が重要: 精度に大きな差がないのであれば、RAGにおいてはLLMへの入力に使う「トークン数」を最も少なくできるフォーマットを選ぶのが賢い選択と言えます。トークン数が少なければ、それだけ処理コストも下がり、効率的です。今回の検証では、CSV形式が最もトークン消費が少なかったため、コスト面で有利である可能性が示唆されました。この検証から、新人エンジニアの皆さんは、RAGシステムを設計する際に、データの見た目を整えることよりも、LLMの性能が十分高ければトークンコストを意識したデータ形式を選ぶことが効率的だと学べます。特に最新モデルを使う場合は、読みやすい整形にこだわるよりも、いかにコンパクトに情報を伝えられるかを考えると良いでしょう。
引用元: https://blog.shibayu36.org/entry/2025/10/14/173000
埼玉にある「ムーミンバレーパーク」へ行ってきた！ ムーミン屋敷のお宅訪問や思わず写真を撮りたくなる景色を紹介埼玉県飯能市にある「ムーミンバレーパーク」の訪問記です。ムーミン屋敷の地下倉庫やキッチン、寝室を探検でき、インスタ映えする写真スポットも満載！原作を知らなくてもショートムービーで楽しめる工夫があります。料理動画投稿者さんならではの視点で、食卓やキッチンへの注目も面白いポイント。子ども向けの遊具やショーもあり、食事もテーマパークとしては良心価格。日々の業務の息抜きに、ムーミンの世界で癒されてみてはいかがでしょうか？
引用元: https://news.nifty.com/article/item/neta/12237-4602453/
お便り投稿フォームVOICEVOX:春日部つむぎ
-
youtube版(スライド付き)関連リンク Cognition Introducing SWE-grep and SWE-grep-mini: RL for Multi-Turn, Fast Context Retrieval
このブログ記事は、AIコーディングエージェントの「速さ」と「賢さ」という、これまでの課題を解決する新技術「SWE-grep」と「SWE-grep-mini」を紹介しています。これは、まるで人間のようにコードベースを理解・探索し、必要な情報を素早く見つけ出すためのAIモデルです。
これまでのAIコーディングエージェントは、複雑なタスクは得意でも、コード検索に時間がかかりすぎて開発者の作業を中断させてしまうという問題がありました。特に、AIエージェントが最初に情報を探し出す「文脈取得」の段階で、作業時間の60%以上を費やすこともあったそうです。
文脈取得の方法には主に2つありました。
埋め込み検索（RAG）: 事前の準備は速いものの、複雑なコードのつながりを追うような検索では不正確になる可能性がありました。 エージェントによる検索: 人間のようにCLIツール（コマンドラインツール）を使ってコードを探索するため柔軟ですが、何度もAIとのやり取りが発生し、非常に時間がかかりました。また、関係ない情報まで大量に読み込んでしまい、AIの判断を鈍らせる「コンテキスト汚染」という問題も抱えていました。そこで登場したのが、今回発表された「SWE-grep」と「SWE-grep-mini」です。これらのモデルは、従来の最先端のAIコーディングモデルと同等の情報検索能力を持ちながら、なんと10倍も速く結果を返します。これにより、AIがコードを理解するためにかかる時間が大幅に短縮され、開発者はWindsurfというツールで「Fast Context（高速な文脈取得）」サブエージェントとして利用できるようになります。デモプレイグラウンドでもその速さを体験できます。
SWE-grepがこれほど高速な理由は以下の通りです。
並列ツール呼び出し: 複数の検索コマンド（grep、ファイル読み込みなど）を同時に実行することで、コードベースの様々な部分を効率よく探索します。従来のAIが1つずつ検索していたのを、同時に8つまで実行できるように訓練されています。 最適化されたツールと高速な推論: 検索ツール自体も高速化され、さらにCerebras社と協力してAIモデルの推論（思考）速度も大幅に向上させています。これらのモデルは、強化学習（RL: Reinforcement Learning）というAIの訓練方法を使って開発されました。特に、報酬関数では、関連性の高い情報を正確に取得することを重視し、「コンテキスト汚染」を避けるように学習させています。
Cognition社は、この「Fast Context」技術を「Fast Agents」という、より広範な目標の第一歩と位置づけています。最終目標は、開発者が集中して作業できる「フロー状態」を維持し、ソフトウェア開発の生産性を最大限に高めることです。AIエージェントの応答速度が、開発者の作業効率に大きく影響すると考えており、わずか5秒という短い「フローウィンドウ」を目標に、AIの賢さと速さの両方を追求しています。
引用元: https://cognition.ai/blog/swe-grep
AIエージェントを支える技術: コンテキストエンジニアリングの現在地AIエージェントは、まるで人間のようにタスクをこなすための技術ですが、その性能を最大限に引き出すためには「コンテキストエンジニアリング」という技術が非常に重要です。新人エンジニアの皆さんも、この考え方を理解することで、AI開発の奥深さに触れることができるでしょう。
コンテキストエンジニアリングとは？これは、大規模言語モデル（LLM）に与える「情報（コンテキスト）」をどう効率的に扱うかを考える技術です。特定のタスクに特化した指示の出し方であるプロンプトエンジニアリングに対し、コンテキストエンジニアリングは、AIが複数回の推論を伴う複雑なタスクをこなすための情報管理全般を指します。例えば、外部の情報を引っ張ってくるRAG（Retrieval Augmented Generation）もこの一部です。
なぜコンテキストエンジニアリングが重要なの？LLMが一度に扱える情報量には限りがあります。情報が多すぎると、必要な情報が埋もれてしまう「Context Rot」という現象が起こり、AIは「本当に必要な情報だけを、適切な量で与える」ことが不可欠であることを示しています。この効率的な情報の与え方が、AIの出力品質を大きく左右するのです。
コンテキストエンジニアリングの3つの手法
情報の取得と生成 (Context Retrieval & Generation) AIがタスクを進める上で、必要な情報をリアルタイムで探し出し、準備する技術です。外部データベースからの情報取得や、ユーザーの質問をより適切な形に書き換えるなどが該当します。 情報の加工 (Context Processing) 取得した情報が使いにくい場合があるため、LLMが理解しやすいように加工します。不要な情報をフィルタリングしたり、長文を要約・圧縮したりします。また、AIに役割や振る舞いを教える「システムプロンプト」の設計や、少数の具体例（Few-shotプロンプティング）を効率的に提示することも含まれます。AIの処理を高速化する「KVキャッシュ」の最適化も重要です。 情報の管理 (Context Management) AIが過去に得た知識や経験を記憶し、次に活かすための技術です。一時的なメモ（Scratchpad）のような短期間の記憶と、永続的に保存される長期的な記憶があります。AIがタスクで失敗した際、その原因を記憶しておくことで、同じ失敗を繰り返さないようにするといった活用も可能です。複数のAIが協力する「マルチエージェント」の場合は、エージェント間で情報が共有され、整合性が保たれるように管理することが非常に重要になります。コンテキストエンジニアリングは、AIエージェントをより賢く、より効率的に動かすための、まさに土台となる技術です。この知識を身につけることで、皆さんのAI開発スキルは格段に向上するでしょう。
引用元: https://tech.algomatic.jp/entry/2025/10/15/172110
【コピペOK】AIエージェントで良いコードを書く！誰でも使える品質向上ルールの設定方法AIエージェントを使った開発はとても便利ですが、「動くコードは作ってくれるけど、品質は大丈夫かな？」と不安に感じることはありませんか？この記事は、AIエージェントに「良いコード」の基準を教え込み、コード品質を向上させるための「共通ルールファイル」の活用法を紹介しています。
なぜAIにルールが必要かというと、プログラミングにおける「良いコード」とは、ただ動くだけでなく、読みやすさ、修正のしやすさ、セキュリティ、処理速度など、さまざまな品質が求められる奥深いものだからです。AIエージェントは、私たちが何も指示しなければ、プロジェクトの文脈（例えば、試作品なのか、お客様に納品する本番用なのか）を自ら判断できないため、「とりあえず動くコード」を優先しがちです。だからこそ、私たちが「ルール」として明確な品質基準を教えてあげる必要があります。
「共通ルールファイル」は、AIに対する開発の指針をまとめたドキュメントで、まるで優秀な先輩エンジニアが隣でアドバイスしてくれるように、AIが常に品質を意識してコードを生成するようになります。このファイルは一度設定すれば、新しいプロジェクトごとに設定し直す必要がなく、多くのプロジェクトで共通の品質基準を保ちながら効率的に開発を進められるのが大きな利点です。
設定方法は非常に簡単で、Claude Code、Codex、Cursorといった主要なAIエージェントの場合、指定された場所にルールファイルを作成し、記事で提供されているルールをコピー＆ペーストするだけで完了します。
新人エンジニアの皆さんが特に意識すべき「良いコード」のポイントとして、記事では以下の8つの観点が紹介されており、これらをAIが考慮するように設定できることで、皆さんの学習にも繋がります。
エラーハンドリング: プログラムで問題が起きたときに、適切に対処し、ユーザーに状況を伝える。 セキュリティ: パスワードの隠蔽や悪意ある入力のブロックなど、プログラムの安全性を確保する。 保守性: 後から機能を追加したり、バグを修正したりしやすいように、整理されたコードを書く。 テスタビリティ: プログラムが正しく動くか確認（テスト）しやすい作りにする。 パフォーマンス: 処理速度が速く、効率的に動くコードにする。 信頼性: 問題が起きても安定して動作し続けるための仕組み（例：エラー時に自動で再試行）を持つ。 可観測性: プログラムが「今どんな状態か」を把握できるように、ログなどを記録する。 スケーラビリティ: 利用者が増えても対応できる、拡張しやすい作りにする。この共通ルールファイルを使うことで、AIは「動くコード」だけでなく「良いコード」を生成する強力なパートナーとなります。初心者の方でも、AIがなぜそのコードが良いのかを説明してくれるため、実践しながらプログラミングスキルを高められるでしょう。設定はたった5分で終わるので、ぜひ試して、より楽しく、自信を持って開発を進めてみてください。
引用元: https://qiita.com/tomada/items/df5d3e0f611860bc2740
アニメとかでプール掃除でキャッキャイチャイチャしてる奴らアニメで描かれるプール掃除は楽しいイベントのように見えますが、この記事は現実の厳しさをコミカルに指摘します。使っていないプールは苔でヌルヌル滑りやすく、怪我の危険も。水は緑色で悪臭が漂い、ヤゴやオタマジャクシがたくさんいるのが実際の姿だそう。プール掃除は重労働で、維持管理も大変だという現実を、クスッと笑える形で教えてくれる楽しい記事です。
引用元: https://anond.hatelabo.jp/20251016003851
お便り投稿フォームVOICEVOX:ずんだもん
-
youtube版(スライド付き)関連リンク Rails: Active Agent gemでRailsに適したAI機能の設計を考察する（翻訳）｜TechRacho by BPS株式会社
この記事は、RailsアプリケーションにAI機能を「Railsらしい」やり方で統合するための「Active Agent」gemについて、その設計思想や具体的な使い方、そして今後の可能性を、日本の新人エンジニアにも分かりやすく解説しています。
Active Agentは、Railsの「規約より設定（Convention over Configuration）」の原則を取り入れ、「Agent」という新しい抽象化を導入します。これは、Railsのコントローラやメーラーのように、AIによるテキスト生成などのロジックをカプセル化（ひとまとめにする）するものです。例えば、簡単なジョークを生成するエージェントも、Rails開発者には馴染み深いクラス定義とメソッド呼び出しで実現できます。AIへの指示文（プロンプト）もAction Viewのテンプレートとして管理できるため、コードとプロンプトを分離でき、変更や管理がしやすくなります。生成処理は、即座に結果を得る同期モードと、バックグラウンドで実行する非同期モードを選べます。
実際のプロジェクトでの活用例として、「オンデマンド翻訳機能」が紹介されています。翻訳エージェントが生成した訳文をデータベースに保存する際、エージェント内で直接データベースを更新するか、それともモデルに任せるかといった設計上の課題を議論し、より「Railsらしい」解決策としてモデル側にロジックを委譲する改善案を提示しています。
AI機能のテストについても触れています。外部のAIサービスに依存しないテストを実現するため、記事ではFakeLLMProviderという偽のAIサービスアダプタを自作する方法を紹介。これにより、本物のAPIを叩かずにAIの応答をシミュレートでき、テストの安定性と速度を向上させることができます。
もう一つの事例は、カンファレンスの「プロポーザルをAIがレビューする機能」です。このエージェントは、発表内容を評価するだけでなく、AIエージェントが過去の発表データベースを検索する「ツール機能」と連携することで、より的確な評価を可能にします。AIからの回答も、JSONのような構造化された形式で受け取れるよう設定でき、プログラムでのデータ処理が容易になります。
記事の後半では、AIアプリケーションの進化に必要な機能として、以下の点が挙げられています。
AI利用のクレジット管理とトラッキング 動的なプロンプト（状況に応じてAIへの指示文を変更） プロンプトインジェクション対策などのセキュリティ機能 複数のAIエージェントが連携する「エージェント型ワークフロー」 過去の会話を記憶する「LLMの記憶容量」 外部情報を活用するRAG（検索拡張生成）のような「コンテキストエンジニアリング」Active Agentは、これらの複雑な要求にも対応できる拡張性を持っており、Rails開発者が愛するRailsフレームワークで、自然かつ効果的にAI機能を組み込めるようになることへの期待が示されています。
引用元: https://techracho.bpsinc.jp/hachi8833/2025_10_14/153720
ファインチューニングは死んだのか？Googleとスタンフォードの論文がAI学習の新しいパラダイムを提示現在のAI（大規模言語モデルエージェント）は、一度失敗した経験から学ぶのが苦手で、同じ間違いを繰り返してしまうという課題を抱えています。まるで、毎回初めてのタスクとして取り組んでいるかのようです。しかし、Googleとスタンフォード大学の最新の研究が、この問題を解決し、AIがより賢く成長するための新しい方法を提案しています。
Googleが開発した「ReasoningBank（リーズニングバンク）」は、AIがタスクを実行した際の成功や失敗の経験を「記憶」として保存し、後で活用するシステムです。人間が日記をつけて過去の出来事を振り返るように、AIの「思考の過程（推論記録）」を構造化して記憶します。そして、新しいタスクに直面したとき、この記憶の中から似たような経験を探し出し、それを参考にして意思決定を行うのです。このシステムを導入したAIは、タスクの成功率が向上し、問題を解決するまでのステップ数も大幅に削減されました。失敗からも学ぶことで、AIは着実に経験を積んで賢くなっていきます。
一方、スタンフォード大学の「ACE（Agentic Context Engineering）」は、AIへの指示文（プロンプト）自体をAIが自律的に改善・進化させていくアプローチです。ACEは「タスクを実行するAI」「実行結果を評価するAI」「評価に基づいて指示文を更新するAI」という3つの役割を持つAIを組み合わせます。タスクの結果を見て、より効果的な指示文になるように、少しずつ改善を加えていくのです。この方法により、AIは状況に適応するまでの時間を大幅に短縮し、処理コストも削減できることが示されました。
これらの研究が示す共通の画期的な点は、AIの「ファインチューニング」と呼ばれる、AIモデルそのものを細かく調整する作業なしに、AIが学習し、性能を向上させられることです。ReasoningBankはAIに外部の「記憶」を与え、ACEはAIの「指示の仕方」を内部的に最適化します。
これにより、AIは単なる計算ツールではなく、まるで人間のように「経験を積みながら自分で学習し、成長していく」新しいフェーズに入りつつあります。AIが「どうすればもっとうまく学習できるか」を自ら学び始める、そんな「記憶を持つエージェント」の時代が到来するかもしれません。これは、AI開発の未来にとって非常に重要な一歩となるでしょう。
引用元: https://note.com/trans_n_ai/n/n92f8092bff4c
Introducing Claude Haiku 4.5Anthropicから、最新の小型AIモデル「Claude Haiku 4.5」がリリースされました！日本の新人エンジニアの皆さんにとって、これはAI開発の現場で「速くて賢いAIを、もっと手軽に使えるようになる」という、とても嬉しいニュースです。
このHaiku 4.5の最大のポイントは、「高性能なのに、ものすごく速くて、しかも安く使える」という点です。なんと、たった5ヶ月前に最先端だった「Claude Sonnet 4」というモデルと比べて、ほぼ同等のコーディング性能を持ちながら、コストは3分の1、速度は2倍以上も向上しています。つまり、以前なら高価で時間のかかったAIの処理が、これからはもっと気軽に試せるようになるわけです。
例えば、AIにリアルタイムでチャットアシスタントをさせたり、お客様対応をさせたり、あるいはプログラミングのペアを組ませるような、応答速度が重要な場面でHaiku 4.5は大活躍します。特に、複数のAIエージェントを使った複雑なプロジェクトや、手早く試作を作りたいラピッドプロトタイピングなど、コーディング作業全般で、これまで以上にサクサクと開発を進められるようになるでしょう。
Anthropicには、現在世界最高のコーディングモデルとされる「Claude Sonnet 4.5」もあります。Haiku 4.5はSonnet 4.5ほどの「究極の知性」は追求していませんが、それに匹敵する性能を「圧倒的なコスト効率」で提供します。状況に応じて、Sonnet 4.5で複雑な問題を分解し、細分化されたタスクを複数のHaiku 4.5に並行して処理させる、といった賢い使い方もできるようになります。
開発者の皆さんは、Claude APIを通じて「claude-haiku-4-5」としてすぐに利用を開始できます。料金も非常に経済的で、入力100万トークンあたり1ドル、出力100万トークンあたり5ドルという設定です。Amazon BedrockやGoogle Cloud Vertex AIでも利用可能なので、普段使っている環境からアクセスしやすいのも魅力です。
安全性にもしっかり配慮されており、Haiku 4.5はこれまでのモデルと比べて不適切な振る舞いをする割合が大幅に低減されています。これは、AIを安心して活用するために非常に重要な点ですね。
Haiku 4.5の登場は、AI開発のハードルをさらに下げ、より多くのアイデアを迅速に形にできる可能性を広げてくれます。新人エンジニアの皆さん、ぜひこの新しい強力なツールを使いこなして、これからのAI開発を楽しんでいきましょう！
引用元: https://www.anthropic.com/news/claude-haiku-4-5
『ジブリ風』と言われるAI生成画像、使わない層はどう思っているのか「この絵柄はもはや『OpenAI風』という印象」「この色ホント苦手」「ジブリ風」と称される特定のAI生成画像がSNSで話題です。多くのユーザーはこれを「OpenAI風」と認識し、本来のジブリとは異なるという意見が出ています。特に、画像特有の黄ばんだ色味や人工的な違和感に不満の声が上がっています。このAI画像は中高年層に多く利用される一方、若年層からは古く感じられており、世代間で美的感覚のギャップが指摘されています。AIが作り出す表現が社会にどう受け入れられるか、エンジニアとして考えるきっかけになるでしょう。
引用元: https://togetter.com/li/2615953
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク Make agents a reality with Amazon Bedrock AgentCore: Now generally available Amazon Web Services
AWSから、AIエージェントを開発し、実際のビジネスで活用するための新しいプラットフォーム「Amazon Bedrock AgentCore」が一般提供開始されました。これは、これまで試作段階にとどまりがちだったAIエージェントを、安全性、信頼性、スケーラビリティを確保しながら、本格的なサービスとして運用するための基盤となるものです。
AIエージェントとは、まるで人間のアシスタントのように、自律的に考え、タスクを遂行するプログラムのことです。例えば、ユーザーの質問に答えたり、情報を収集したり、複数のシステムを連携させて複雑な業務を自動化したりできます。しかし、これを企業レベルで安全かつ効率的に運用するには、多くの技術的な課題がありました。AgentCoreは、そうした課題を解決し、開発者がエージェントを素早く本番環境に導入できるように設計されています。
AgentCoreの主な特徴は以下の通りです。
柔軟な開発: 開発者は、Amazon Bedrockで提供されるAIモデルだけでなく、OpenAIやGoogle Geminiなど外部のモデル、そしてLangChainやCrewAIといったお好みの開発フレームワークを使って、自由にエージェントを構築できます。 豊富なツール連携: エージェントがコードを安全に実行できる「Code Interpreter」や、ウェブサイトを操作できる「Browser」機能が組み込まれています。また、既存の社内システムやAPIをエージェントから簡単に呼び出せるようにする「Gateway」機能もあり、エージェントはより多くのタスクを実行できるようになります。 賢い記憶力: 過去の会話や操作履歴を覚え、文脈を理解しながら対応する「インテリジェントメモリ」機能により、エージェントはより賢く、パーソナルな体験を提供できます。 運用と監視: エージェントの動作を詳細に監視し、問題が発生した場合に素早く原因を特定できる機能（Observability）が提供されます。また、予測不能な負荷にも自動で対応し、長時間のタスクでも安定して稼働できる信頼性の高い実行環境（Runtime）も備わっています。 高いセキュリティ: 高度なセキュリティ機能が組み込まれており、機密データを安全に扱いながら、企業システムにアクセスできます。すでに、Amazon社内の製造プロセス自動化、医療分野での承認審査効率化、通信大手エリクソンやソニーグループでのAI活用など、様々な業界でAgentCoreが活用され、大きな成果を上げています。
AgentCoreは東京リージョンを含む世界9つのAWSリージョンで利用可能なので、日本のエンジニアの皆さんも、これらの強力な機能を使って、アイデアを素早く形にし、AIエージェントの可能性をビジネスに活かしていくことができます。
引用元: https://aws.amazon.com/blogs/machine-learning/amazon-bedrock-agentcore-is-now-generally-available/
Securing your agents with authentication and authorizationAIエージェントは、チャットだけでなく、ファイル操作やメッセージ送信、外部ツールの利用といった「行動」ができる点が大きな特徴です。そのため、従来のAIアプリケーションよりもセキュリティ対策が重要になります。特に「認証（Authentication）」と「認可（Authorization）」は、エージェントを安全に運用するために欠かせない要素です。
認証（AuthN）と認可（AuthZ）の基本認証とは「あなたが誰であるか」を確認するプロセスです。例として、システムにログインする際にユーザー名とパスワードで本人確認をするのが認証です。一方、認可とは「認証されたあなたが何ができるか」を判断し、アクセス権限を制御するプロセスです。この二つは合わせて「認証認可（Auth）」と呼ばれ、あらゆるアプリケーションで重要ですが、AIエージェントには特有の課題があります。
AIエージェントが従来のアプリケーションと違う点
多くのサービスへのアクセス: エージェントは、従来のアプリケーションよりもはるかに多くの異なるサービスやツール（例：メール、カレンダー、データベースなど）にアクセスする必要があります。 動的に変化するアクセス要件: エージェントの行動は、その時々の状況によって必要な権限が大きく変わるため、柔軟なアクセス制御が必要です。 監査の複雑さ: 多くのサービスをまたいで行動するため、エージェントが行った操作の記録（監査ログ）があちこちに分散し、全体の動きを追跡・確認するのが難しくなります。これらの課題に対応するため、将来的にはエージェントの認証認可を一元的に管理する新しいシステムが必要になると考えられています。しかし、現在の技術でもエージェントのセキュリティは確保できます。
現在のAIエージェントの認証認可エージェントも基本的にはリソースにアクセスするソフトウェアであるため、既存の認証認可技術である「OAuth 2.0」や「OIDC」といった業界標準のフレームワークを効果的に利用できます。エージェントのアクセスパターンは大きく二つに分けられます。
委任アクセス (Delegated Access): エージェントがユーザーの「代理」としてリソースにアクセスする場合です。例えば、メールアシスタントがユーザーの許可を得てメールボックスにアクセスし、メールを処理するようなケースです。 この場合、「Auth Code Flow」と「OBO (On-Behalf-Of) Token Flow」といったOAuth 2.0のフローが主に使われます。 直接アクセス (Direct Access): エージェントが人間の関与なしに、自律的にリソースにアクセスする場合です。例えば、セキュリティエージェントが自動でシステムログを監視し、異常を検知するようなケースです。 この場合、「Client Credentials Flow」というOAuth 2.0のフローが主に使われます。まとめAIエージェントの能力が高まり、自律性が増すにつれて、認証認可の重要性はますます高まります。OAuth 2.0などの既存の標準技術を理解し、適切に活用することが、安全なエージェントを開発するための第一歩です。特に「Auth Code Flow」「OBO Token Flow」「Client Credentials Flow」の3つのフローは、多くのエージェントにおけるアクセス制御で役立つでしょう。
引用元: https://blog.langchain.com/agent-authorization-explainer/
StreamingVLM: Real-Time Understanding for Infinite Video Streams最近注目されている「画像とテキストを同時に理解するAIモデル（VLM）」は、私たちが普段使っているAIアシスタントや、自動運転のような自律的に動くシステムにおいて、動画をリアルタイムで理解するための鍵となります。しかし、現在のVLMには大きな課題がありました。それは、終わりなく続く長い動画ストリームを処理する際に、システムが遅くなったり、メモリを使いすぎたりすることです。
従来のやり方では、動画全体を一度に処理しようとすると、動画が長くなるほど計算量が爆発的に増え（動画の長さの2乗に比例！）、現実的ではありませんでした。また、動画を区切って少しずつ処理する「スライディングウィンドウ方式」という方法もありますが、これだと動画全体の文脈が途切れてしまったり、同じ部分を何度も計算し直すために無駄な処理が多く発生し、結局遅延につながっていました。
このような課題を解決するため、この論文では「StreamingVLM」という新しいモデルを提案しています。StreamingVLMは、無限に続く視覚情報（動画）を、リアルタイムかつ安定して理解できるように設計されています。
彼らのアプローチのポイントはいくつかあります。まず、AIモデルの学習方法と、実際に動かす推論方法を統一した枠組みで考えることで、より効率的な処理を実現しています。推論時には、AIが過去の情報を記憶しておくための「KVキャッシュ」という領域をコンパクトに保つ工夫がされています。具体的には、重要な情報（アテンションシンク）を再利用したり、直近の短い動画フレームの情報と、直近の長いテキストの情報をうまく組み合わせたりして、必要な情報だけを効率的に保持します。
このリアルタイム処理能力は、シンプルな「教師ありファインチューニング（SFT）」という学習方法によって実現されています。これは、全体を一度に見るのではなく、短いながらも少しずつ重なる動画の塊（チャンク）を使って学習させることで、非常に長い動画を処理するための特殊な学習をせずとも、実際の推論時と同じようなアテンションの動きをモデルに覚えさせることができます。
StreamingVLMの性能を評価するために、研究チームは平均2時間以上という超長時間の動画を含む、新しい評価基準「Inf-Streams-Eval」を作成しました。このベンチマークで、StreamingVLMは競合する「GPT-4O mini」に対して66.18%の勝率を達成し、NVIDIA H100という高性能なGPU一枚で、1秒間に最大8フレームという安定したリアルタイム処理を実現しています。さらに、このSFT学習戦略は、特定の画像質問応答（VQA）タスク向けのチューニングなしに、一般的なVQA能力も向上させ、他の主要なベンチマークでも優れた結果を出しています。
このStreamingVLMは、将来のAIアシスタントや自律エージェントが、長く続く動画をスムーズに理解し、より賢く、より役立つ存在になるための重要な一歩と言えるでしょう。コードも公開されており、さらなる発展が期待されます。
引用元: https://arxiv.org/abs/2510.09608
イラストレーターさん「あなたの愛猫を描きます！」企画に寄せられた猫の開き画像が豪快すぎて笑顔になるイラストレーター「はいらずんば@猫スケッチ」さんの「あなたのうちの子描きます」企画が注目を集めました。応募された写真の中でも、大胆に寝そべる猫の「豪快な開き」ポーズが特に話題に。「お股パッカーン」や「お手てのむん！」といった可愛らしい姿が多くの人の笑顔を誘い、SNS上で大きな反響を呼んでいます。猫の愛らしい一面が心を和ませる、楽しいニュースです。
引用元: https://togetter.com/li/2615511
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク The Tiny Teams Playbook
この記事は、AIエージェントの進化が加速する現代において、少人数ながらも高い生産性を誇る「Tiny Teams」の成功戦略をまとめたものです。日本の新人エンジニアの皆さんが、これからのチームでの働き方やAIとの協業を考える上で、貴重なヒントとなるでしょう。
「Tiny Teams」とは、従業員数よりも多くの年間経常収益（ARR）を生み出す、極めて効率的なチームのことです。AIが知識労働を自動化・拡張できるようになった今、AIを最大限に活用し、スピードと効率性で大きな成果を出す新しい組織の形として注目されています。
AI Engineer Summitで共有された、成功しているTiny Teamsからの普遍的なアドバイスは以下の通りです。
採用 (Hiring) 厳選された優秀人材: 真に期待できる候補者のみ採用。 有給ワークトライアル: 短期間のプロジェクトで適性を見極める。 製品からの採用: サービスに熱意ある顧客をチームに招く。 高水準の報酬: 優秀な人材には、相応の給与で高いモチベーションを維持。 少人数のベテラン「ジェネラリスト」: 幅広いスキルを持つ経験豊富なメンバーで構成。 文化と価値観 (Culture & Value) 「低エゴ、高信頼」: 信頼に基づき、迅速な意思決定を促進。 自立心、粘り強さ、レジリエンス: 困難に屈せず、解決策を探す姿勢。 徹底した透明性と責任: 進捗や課題を共有し、各自が責任を持つ。 ユーザー中心: 顧客のフィードバックを重視し、喜ばれる製品開発。 連帯感とスピード: 楽しみながら素早く行動し、チームの活力を維持。 運営 (Operations) 会議を最小限に: 「深い集中」の時間を確保し、生産的な作業を優先。 AIを「Chief of Staff」として活用: リサーチやマーケティングをAIで自動化。 AIによるカスタマーサポート: 顧客対応の効率化と品質向上。 優先順位付け（Let Fires Burn）: 重要な課題に集中し、全てを解決しようとしない。 「二度と学ばない」知識共有: 再利用可能なテンプレートで効率的な学習と活用。 対面での交流: オフィスや合宿でチームの結束を強化。 技術と製品 (Tech and Product) シンプルで堅実な技術スタック: メンテナンスしやすく信頼性の高い技術を選択。 シンプルな製品から開始: 核となる機能に絞り、迅速にリリース。 フィーチャーフラグによる実験: 新機能を段階的に導入し、ユーザーの反応を確認。 独自のベンチマーク作成: LLMの性能評価など、製品改善のための評価システムを構築。これらの戦略は、AIを活用し大きな成果を出しているチームから学んだ知見です。新人エンジニアの皆さんも、効率的なチームのあり方やAIとの協業について考える上で、ぜひこれらのヒントを活用してください。
引用元: https://www.latent.space/p/tiny
Every LLM Is Its Own Media Channel AIVO JournalLLMは全部同じじゃない！それぞれのAIで「情報の見つけ方」が違う理由
多くのエンジニアやマーケターは、ChatGPT、Gemini、ClaudeのようなLLM（大規模言語モデル）を「AI」として一括りに見てしまいがちです。しかし、この記事は、これらのLLMがそれぞれ独自の「情報の収集方法」や「評価基準」を持つ、全く異なる情報チャネルであると警鐘を鳴らしています。まるでGoogle、Meta、TikTokを同じものとして扱うのが間違いであるように、LLMも個別に戦略を立てる必要があるというのです。
なぜLLMごとに情報の見つけ方が違うのでしょうか？
ChatGPT-4o/o1: 特徴: 「最新の情報」と「信頼できる情報源」を非常に重視します。タイムスタンプが新しく、人間がレビューした情報や、公式なライセンスを持つメディアのコンテンツが優先されます。 ポイント: 情報の「鮮度」と「出どころの信頼性」が鍵です。 Gemini 1.5 Pro: 特徴: Googleの知識グラフ（Knowledge Graph）と深く連携し、「具体的な『モノ』や『概念』と結びついたデータ（エンティティリンクされたデータ）」を重視します。情報が決められたデータ形式（スキーマ）で構造化されていると、見つけてもらいやすくなります。 ポイント: 情報が「何について」のもので、その構造が「明確である」ことが重要です。 Claude 3.5 Sonnet/Opus: 特徴: 「情報の信頼性」と「倫理的な価値観との整合性」を厳しく評価します。過度に最適化されたり、推測に基づいたりするコンテンツは評価が低く、専門家が監修し、中立的な表現で、安全性が確認された情報を好みます。 ポイント: 情報の「客観性」と「質の高さ」が求められます。これらのLLMが今後も統合される可能性は低いと筆者は指摘します。それは、データ収集のライセンスや各国・地域の法律（ガバナンス）が異なるため、各LLMが独自のエコシステムとして進化していくからです。
新人エンジニアが意識すべきことLLMを活用したサービスやアプリケーションを開発する際、この違いを理解することが非常に重要です。
データの準備: 各LLMが重視するポイントに合わせて、データの鮮度、構造化、信頼性を考慮して準備しましょう。 プロンプト設計: 例えば、ChatGPTには最新情報へのアクセスを促すプロンプト、Geminiには構造化されたデータの参照を促すプロンプト、Claudeには中立的で信頼できる情報源を求めるプロンプトなど、LLMの特性を活かした設計が求められます。 コンテンツ作成: LLMに生成させるコンテンツや、LLMが参照する外部コンテンツを作成する際も、それぞれのLLMの評価基準に合致するように工夫が必要です。まとめると、LLMは「単一のAI」ではなく、「個別の特性を持つ情報収集・評価システム」です。それぞれのLLMの個性を見極め、それに合わせたアプローチを取ることが、これからのAI時代で成功するための重要な視点となるでしょう。
引用元: https://www.aivojournal.org/every-llm-is-its-own-media-channel/
Huawei、LLMの精度を保持したまま最大70%メモリ削減できる新手法を発表──コンシューマーGPUでの高精度生成AI実行も視野に Ledge.aiHuaweiが、大規模言語モデル（LLM）をもっと手軽に、そして高性能なGPUがなくても利用できるようにする画期的な新技術「SINQ（Sinkhorn-Normalized Quantization）」を発表しました。これは、AIの精度を保ったまま、AIが動くコンピューターのメモリ使用量を大幅に削減できる技術です。
最近注目されているChatGPTのようなLLMは非常に賢いですが、動かすためには膨大なメモリ（VRAM）を積んだ高性能なグラフィックボード（GPU）が必要です。そのため、多くの人が手元のPCで気軽に試したり、スマートフォンなどの小さなデバイスにAIを組み込んだりするのは難しいという課題がありました。
SINQは、AIモデルのデータ（重み）を「量子化」という技術で圧縮し、メモリ消費を抑える手法です。従来の量子化では、データを圧縮するとAIの精度が落ちてしまいがちで、その精度を元に戻すために「再調整（キャリブレーション）」という手間のかかる追加作業が必要でした。しかし、SINQの最大の特徴は、この再調整が一切不要になる点です。
この技術の核となるのは、「Sinkhorn-Knoppアルゴリズム」という数学的な手法の応用です。AIモデルの重みデータに存在する「外れ値」（極端に大きい・小さい値）が特定の場所に偏るのを防ぎ、データ全体が均一に分散されるように調整します。これにより、データを大幅に圧縮しても、AIの予測精度をほとんど損なうことなく維持できるのです。
具体的な成果としては、AIの精度を高く保ったまま、メモリ使用量を最大70%も削減できます。これは非常に大きな進歩で、例えば、私たちが普段使うような8GB程度の一般的なグラフィックボードでも、これまで専門的な高性能GPUでしか動かせなかったような大規模なLLM（Qwen3-7Bモデルなど）を動かせるようになることを意味します。さらに、データ圧縮の処理自体も非常に高速で、従来の再調整が必要な手法と比べて最大30倍も速いと報告されています。
SINQは、HuaweiのQwenシリーズだけでなく、Llama 2やLlama 3など、様々なLLMに適用できる汎用性の高さも魅力です。これにより、高性能なGPUに頼らずにLLMを運用する道が開かれ、手元のPCやエッジデバイス（小型の端末）でも高品質な生成AIが使える未来が近づきます。この技術のコードはGitHubで公開されており、世界中のエンジニアが自由に試したり、さらに応用したりすることが期待されています。
この技術は、将来皆さんが少ないリソースでAIアプリを開発したり、AIを様々な製品に組み込んだりする際に、とても役立つ基礎技術になるでしょう。AIの可能性を広げる、重要な一歩と言えます。
引用元: https://ledge.ai/articles/huawei_sinq_quantization_llm
カイジの絵が下手だと思っていた時期があったが、いざ模写してみると圧倒的な上手さに気づいた話「ピカソの絵を下手だと評することと同じ」漫画『カイジ』の絵は、独特なタッチのため『下手』と思われがちですが、実はプロも認める『圧倒的な巧みさ』を持つと話題です。実際に模写すると、キャラクターの個性、読者を惹き込む視線誘導、コマ割り、心理描写といった『漫画としての総合力』の高さに気づかされます。これは表面的な印象で判断せず、奥にある本質や技術を見抜く大切さを教えてくれます。新人エンジニアの皆さんも、一見シンプルなものに隠された深い工夫を探求する視点を持つ良いきっかけとなるでしょう。
引用元: https://togetter.com/li/2615004
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク From Assistant to Adversary: Exploiting Agentic AI Developer Tools
最近、CursorやGitHub CopilotといったAIを活用した開発ツールが広く利用され、開発効率の向上に貢献しています。しかし、この記事ではこれらの「自律型AI開発ツール」が新たなセキュリティ上の脅威をもたらす可能性と、その対策についてNVIDIAが分析した内容を解説しています。
自律型AI開発ツールは、LLM（大規模言語モデル）の力で、ユーザーの指示やコードを理解し、ファイルの編集、コマンド実行といった様々なアクションを自律的に行います。この自律性が開発を加速させる一方で、AIエージェントが行動できる範囲が広いほど、その動作は予測しにくくなり、攻撃者による悪用のリスクが高まることが指摘されています。
記事では、攻撃者がGitHubのプルリクエストやイシューに巧妙に悪意のある指示（「間接プロンプトインジェクション」）を仕込むことで、開発者のPCで不正なコードを実行させる具体的な手口が紹介されています。例えば、攻撃者は一見無害な偽のPythonパッケージを作成し、それをプロジェクトの依存関係として追加するプルリクエストを送信します。もし開発者がAIエージェントを使ってこのプルリクエストをレビューさせると、エージェントがそのパッケージをインストールする際に、パッケージに仕込まれた悪意のあるコード（例えば、PCを遠隔操作されるリバースシェル）が実行されてしまう可能性があります。Cursorのようなツールには一定のセキュリティ対策が講じられていますが、記事では巧妙な手法でこれらの対策を迂回できる場合があることも示されています。
このような攻撃から身を守るために、以下の対策が推奨されています。
「プロンプトインジェクションは常に起こり得る」という前提でAIシステムを設計する。 AIエージェントの自律性をできるだけ制限し、特定の決まった作業のみを許可する。 信頼できないデータ（外部からのプルリクエストなど）を扱う際には、必ず人間が内容を確認し承認する仕組み（Human-in-the-loop）を導入する。 もし完全な自律稼働が必要な場合は、仮想マシン（VM）やコンテナのような隔離された環境でエージェントを実行し、アクセスできるリソースを最小限に抑える。NVIDIAが提供する脆弱性スキャナー「garak」や、安全なやり取りをサポートする「NeMo Guardrails」のようなツールを活用することも有効です。AIエージェントの活用は開発を大きく加速させる可能性を秘めていますが、その潜在的なリスクを正しく理解し、適切なセキュリティ対策を講じることが、安全に開発を進める上で不可欠です。
引用元: https://developer.nvidia.com/blog/from-assistant-to-adversary-exploiting-agentic-ai-developer-tools/
Embracing the parallel coding agent lifestyle皆さん、こんにちは！今回は、複数のAIコーディングエージェントを同時に活用して、ソフトウェア開発を効率的に進める新しい働き方についてご紹介します。筆者自身も最初は懐疑的でしたが、実践してみると非常に効果的だと感じているそうです。
このアプローチは、AIに得意な作業を複数並行して任せることで、私たちエンジニアがコードのレビューや設計など、より重要なタスクに集中できるようになる、という考え方に基づいています。新人エンジニアの皆さんも、ぜひこの発想を取り入れてみてください。
具体的に、AIエージェントを並行して使うことで、どのような作業が効率化できるのでしょうか？
新しい技術の調査や概念実証（PoC）:「この新しいライブラリは使えるか？」「この技術で何ができるか？」といった、未知の領域を探る初期段階の作業をAIに任せます。AIは関連するコードを読み解き、プロトタイプを作成してくれるので、私たちが手探りで調べる手間を大幅に削減できます。
既存システムの動作原理の確認:自分のプロジェクトのコードベースで「この機能はどう動いているんだっけ？」と疑問に思った時、AIに質問すれば、コード全体を分析し、詳細な説明を短時間で提供してくれます。これにより、複雑なシステムの理解を素早く深めることができます。
小さなメンテナンスや軽微な修正作業:テスト実行中に発生する警告の解消や、簡単なバグ修正など、本来であれば集中力を妨げるような細かい作業をAIに依頼できます。メインの作業を中断することなく、AIが裏でこれらの「ちょっとした困りごと」を解決してくれるので、非常にスムーズです。
具体的な指示に基づく開発作業:「こういう機能を作ってほしい。実装方法も具体的に指示する」というように、詳細な仕様をAIに与えることで、期待通りのコードを生成させることができます。これにより、生成されたコードのレビューにかかる時間も短縮され、効率的に開発を進められます。
筆者は現在、複数のAIエージェントを様々な環境で同時に動かし、並行処理を行う開発スタイルを実践しています。リスクの高い作業では、万が一の事態に備えて安全な方法を選ぶなど、状況に応じた使い分けが重要です。AIを駆使した開発はまだ発展途上ですが、LLM（大規模言語モデル）の進化によってその可能性は大きく広がっています。新人エンジニアの皆さんも、この新しい働き方を積極的に試し、自身の生産性向上につなげていきましょう。
引用元: https://simonwillison.net/2025/Oct/5/parallel-coding-agents/
OpenAI Agent Builderを触ってみた：Difyとの違いと実践TipsOpenAIが2025年にリリースした「Agent Builder」は、AIエージェントの開発をぐっと身近にする新しいツールです。コードを書かなくても、視覚的にノードを繋いでワークフローを組み立てられるため、初心者でも直感的にAIエージェントを作ることができます。開発は「設計」「公開」「デプロイ」の3ステップで、プレビュー機能で動作をすぐに確認できるため、効率的に試行錯誤できます。
類似ツールであるDifyとの比較では、Agent BuilderはOpenAI公式のため、GPT-5などの最新モデルやChatKitとの連携がスムーズで、シンプルさとセキュリティが標準で備わっています。一方Difyはオープンソースで、多様なLLM（大規模言語モデル）に対応し、カスタマイズ性が高く、オンプレミス運用も可能です。OpenAIの技術を素早く試したいならAgent Builder、より柔軟な開発や自社環境での運用が必要ならDifyを選ぶのが良いでしょう。
Agent Builderのワークフローは、「Agent（AIモデル本体）」「File Search（検索）」「If/else（条件分岐）」などのノードを組み合わせて作成します。エージェントを設計する際は、一つのエージェントに多くの役割を持たせるのではなく、「質問分類」「情報検索」「回答生成」のように役割を分担させると、より良い性能を発揮します。
AIエージェントは悪意のある入力に弱いため、セキュリティ対策が欠かせません。「プロンプトインジェクション」や「データ漏洩」を防ぐために、出力形式の制限、人間による承認（Human approval）、Guardrailsといった機能を使うことが推奨されます。特に外部ツールと連携する際は、慎重な設定が必要です。
作成したエージェントは、ChatKitを使えば簡単にウェブサイトなどに組み込んでチャットUIとして利用できます。
開発をスムーズに進めるための実践的なヒントもあります。例えば、既存のテンプレートから始めること、ワークフローにコメントを残して設計意図を明確にすること、開発中のコスト（トークン消費）を意識すること、そしてエージェントの品質を定期的に評価することです。また、安全性とユーザー体験のバランスを考え、データ削除や外部送信など本当に重要なアクションにのみ人間による承認（Human approval）を配置しましょう。
Agent BuilderはAIエージェント開発のハードルを下げ、多くのアイデアを形にする可能性を秘めています。セキュリティ対策やコスト管理をしっかり行いながら、新しいAIプロダクト開発に挑戦してみましょう。
引用元: https://qiita.com/akira_papa_AI/items/7344e21b9204526e5127
世界最小の哺乳類「トウキョウトガリネズミ」を見に行ってきた！ 東京にいなくてネズミでもない“トガリネズミ”は、可愛い姿で毒を使うハンターだった東京にはいない「トウキョウトガリネズミ」は、ネズミではなくモグラの仲間で、体重わずか2gの世界最小哺乳類です。4時間以上食べないと餓死するほど代謝が速く、なんと毒を使って獲物を麻痺させるハンターでもあります。北海道に生息する絶滅危惧種で、可愛らしい見た目と意外な生態のギャップが魅力。熱心な投稿者が展示会に足繁く通って撮影した、貴重なトガリネズミたちの動画が話題になりました。
引用元: https://news.nifty.com/article/item/neta/12237-4573333/
お便り投稿フォームVOICEVOX:ずんだもん
-
youtube版(スライド付き)関連リンク Introducing the Gemini 2.5 Computer Use model
Google DeepMindは、AIがコンピューターのユーザーインターフェース（UI）を直接操作できるようになる画期的な新モデル「Gemini 2.5 Computer Use」を発表しました。このモデルは、Gemini 2.5 Proの持つ「見て、考えて、判断する」高度な視覚理解と推論能力をベースに開発されており、AIエージェントがまるで人間のようにWebサイトやアプリケーションを操作できるようにすることを目的としています。
このモデルの大きな特徴は、Webやモバイルの制御に関するテスト（ベンチマーク）において、既存のどのモデルよりも高い性能を発揮し、しかも応答速度（レイテンシー）が非常に速い点です。具体的には、Webページのフォームに情報を入力したり、ドロップダウンメニューを選んだり、ログインが必要なページを操作したりといった、これまでAIだけでは難しかったデジタルタスクをスムーズにこなすことができます。
技術的な仕組みとしては、Gemini APIを通じて提供される「computer_use」という特別なツールを使います。AIは、現在の画面のスクリーンショット、ユーザーからの指示、そして過去にどのような操作をしたかという履歴情報を受け取ります。これらを分析して、「このボタンをクリックする」「ここに文字を入力する」といった具体的なUIアクションを判断し、実行します。もし、購入などの重要な操作が必要な場合は、ユーザーに確認を求める機能も備わっています。この一連のプロセスを繰り返すことで、AIが自律的にタスクを完了させることが可能です。現在のところ、主にWebブラウザでの操作に最適化されていますが、モバイルアプリのUI制御においても大きな可能性を秘めています。
AIがコンピューターを直接操作できるようになるため、Google DeepMindは安全性を非常に重視しています。モデル自体に、意図しない誤操作や悪用を防ぐための安全機能が最初から組み込まれています。さらに、開発者向けにも、システムを破壊したり、セキュリティを侵害したりするような高リスクなアクションをAIが勝手に実行しないよう、細かく設定できる安全制御機能が提供されています。Googleは、この新しい技術を導入する際には、開発者がシステムを徹底的にテストするよう強く推奨しています。
すでに早期アクセスプログラムでは、このモデルが様々な分野で活用され、大きな成果を上げています。例えば、ソフトウェア開発におけるUIテストの自動化により、開発スピードが飛躍的に向上したり、個人のタスク管理アシスタントや企業内のワークフロー自動化に利用されたりしています。Google社内でも、決済プラットフォームの脆いUIテストをAIが自動で修復するといった活用例があり、最大で60%以上のテストをAIが立て直すことに成功しているとのことです。
この「Gemini 2.5 Computer Use」は現在、Google AI StudioやVertex AIを通じて、パブリックプレビュー版として利用可能です。日本の新人エンジニアの皆さんも、この新しいAI技術に触れて、未来の自動化やAIエージェント開発の可能性をぜひ体験してみてください。
引用元: https://deepmind.google/discover/blog/introducing-the-gemini-2-5-computer-use-model/
Agents Playwright「Playwright Agent」は、人気のWebテストフレームワークPlaywrightに標準で組み込まれた、AIの力を活用したテスト自動化支援機能です。新人エンジニアの皆さんにとっては、テストコードを書く手間を大幅に減らし、より効率的に品質の高いWebアプリケーションを開発できるようになる、強力なツールだと考えると良いでしょう。
このPlaywright Agentには、主に3つの「エージェント」と呼ばれる仕組みが含まれています。これらはそれぞれ異なる役割を持ち、連携しながらテストの作成から修復までを自動的に進めます。
🎭 Planner（プランナー）:このエージェントは、皆さんのWebアプリケーションを自動的に探索し、「何をテストすべきか」という計画を、人間が理解しやすいMarkdown形式のドキュメントとして作成します。例えば、「ユーザーが商品をカートに追加し、購入を完了する」といった具体的なシナリオを設計する手助けをしてくれます。
🎭 Generator（ジェネレーター）:プランナーが作成したMarkdown形式のテスト計画を受け取り、それを基に、実際に実行可能なPlaywrightのテストコードを自動的に生成します。Webページのボタンや入力フォームなどの要素を正しく識別し、期待される動作を検証するコードを効率的に作り出してくれます。これにより、手作業でテストコードを一から書く時間を大幅に短縮できます。
🎭 Healer（ヒーラー）:WebアプリケーションのUI変更などでテストコードが動かなくなった場合、このエージェントが活躍します。ヒーラーは、失敗したテストを自動で検知し、その原因を分析します。そして、例えばUI要素の指定（セレクタ）が変わっていた場合に新しいセレクタを提案したり、処理の待機時間を調整したりするなど、テストを修正するための「パッチ」を自動で適用しようとします。これにより、テストのメンテナンス作業が非常に楽になります。
これらのエージェントは、それぞれ単独で使うこともできますが、順番に連携させて使うことで、アプリケーション全体に対する包括的なテストカバレッジ（網羅性）を自動的に生み出すことができます。
導入も簡単で、npx playwright init-agentsというコマンド一つで、プロジェクトにエージェントの定義を追加できます。その後は、VS CodeなどのAIツールと連携して、これらのエージェントに指示を出し、Playwrightテストの作成や修復を自動で行わせることが可能になります。
Playwright Agentは、テスト作成の初期段階からメンテナンスまで、テスト工程全体の効率化を強力にサポートし、エンジニアがより本質的な開発作業に集中できるようにするための画期的な機能と言えるでしょう。
引用元: https://playwright.dev/docs/test-agents
エージェント機能が大幅に強化されたPLaMo 2.1 Primeの提供開始 - 株式会社Preferred Networks皆さん、こんにちは！今回は、国内のAI技術をリードする株式会社Preferred Networks（PFN）から発表された、日本のエンジニアにとって注目のニュースをご紹介します。PFNが独自に開発している国産の大規模言語モデル（LLM）「PLaMo™（プラモ）」の商用版「PLaMo 2.1 Prime」がリリースされ、特に「エージェント機能」が大きくパワーアップしたとのことです。
エージェント機能とは、AIが単に質問に答えるだけでなく、まるで秘書のように、ユーザーの指示を理解して、必要な情報を自動で探し出し、様々なシステムと連携してタスクをこなしてくれる機能のことです。
今回の「PLaMo 2.1 Prime」で特に注目すべきは、「自動ツール連携」機能が実装された点です。これまでのPLaMoも外部システムと連携できましたが、2.1 Primeでは、ユーザーの指示に合う最適なツール（たとえば、Web検索、社内のデータベース、外部のAIエージェント、APIなど）をPLaMoが自分で判断して選び、複数組み合わせて使うことができるようになりました。これにより、AIがより複雑で高度な仕事をこなせるようになります。
例えば、具体的な活用イメージとして以下が挙げられています。
お客様からの問い合わせに対して、PLaMoが「顧客管理システム」で情報を確認し、「在庫管理システム」で在庫状況を調べて、それらの情報をまとめてお客様に回答するといった、複数の情報を連携させた高度な対応が可能になります。 特定のキャンペーンに興味を持ちそうな顧客を社内システムから自動で抽出し、その顧客向けにパーソナライズされたメールの本文をPLaMoが生成、さらにそのメールを自動で送信するといった一連の業務を任せることもできるようになります。このような自動ツールの選択や呼び出しの精度は、専門のベンチマークテスト「BFCL V3」でも高い評価を得ています。これは、PLaMoがユーザーの意図を正確に汲み取り、必要な情報を適切な方法で引き出す能力が大きく向上したことを意味します。他の大規模言語モデルと比較しても、特定のツール呼び出し能力においてはPLaMo 2.1 Primeが優れている場面があるというのは、国産LLMの大きな進化を感じさせますね。
PLaMoは、PFNが日本語データを使って一から開発した、日本語の扱いに特に長けたLLMです。PLaMo Primeの他にも、自動車などのエッジデバイス向けに軽量化されたPLaMo Liteや、学術・研究用のPLaMo-100B、金融特化型、翻訳特化型など、用途に合わせた様々なモデルが提供されています。今回のアップデートは、PLaMoがさらに多様なビジネスシーンで活躍するための大きな一歩となるでしょう。
国産のAI技術が私たちの仕事や生活をどう変えていくのか、新人エンジニアの皆さんもぜひ注目してみてください！
引用元: https://www.preferred.jp/ja/news/pr20251007-2/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク Google DeepMind introduces new AI agent for code security
Google DeepMindは、ソフトウェアのセキュリティを自動で強化する新しいAIエージェント「CodeMender」を発表しました。この画期的なツールは、AIの力でコードの脆弱性を発見し、修正することを目指しています。
現在のソフトウェア開発では、セキュリティの脆弱性を見つけて修正する作業が非常に難しく、多くの時間と労力を必要とします。従来の自動チェックツール（「ファジング」と呼ばれる多様な入力を与えてバグを探す手法など）にも限界があり、AIによる高度な脆弱性発見技術が進化するにつれて、人間だけで全ての脆弱性に対応するのは非現実的になってきています。CodeMenderは、このセキュリティ上の大きな課題を解決するために開発されました。
CodeMenderは、大きく分けて2つのアプローチでコードセキュリティを強化します。
リアクティブ（即時修正）: 新しく見つかった脆弱性を素早く自動で修正します。 プロアクティブ（根本的改善）: 既存のコードをより安全な形に書き換え、将来の脆弱性の発生を防ぎます。例えば、特定の種類の脆弱性を根本からなくすような大規模なコード改修も行います。このAIエージェントは、Googleの最先端AIモデルである「Gemini Deep Think」をベースにしています。そのため、人間のようにコードについて深く考え、複雑な問題を解決する能力を持っています。CodeMenderは、以下のような強力なツールや技術を組み合わせてコードの分析と修正を行います。
高度なプログラム分析: 「静的解析」（コードを動かさずに文法や構造を調べる）、「動的解析」（コードを実際に動かして振る舞いを調べる）、「差分テスト」、「ファジング」、そして「SMTソルバー」（論理的な問題を解く技術）などを駆使し、脆弱性の根本原因や設計上の弱点を特定します。 マルチエージェントシステム: 特定の課題に特化した複数のAIエージェントを連携させることで、複雑な問題にも効率的に対応します。例えば、コードを修正した後、元の機能が損なわれていないか（「デグレード」していないか）を自動で検証するエージェントも存在します。CodeMenderが生成したコードの変更は、自動で徹底的に検証されます。これにより、「問題の根本原因が本当に解決されているか」「機能が壊れていないか」「コーディング規約に沿っているか」など、様々な観点から修正の品質が保証されます。人間が最終確認すべきは、この検証をクリアした「質の高いパッチ」のみとなるため、開発者の負担を大幅に軽減できます。
Google DeepMindは、これまでにCodeMenderを使ってオープンソースプロジェクトに72件ものセキュリティ修正を提供してきました。中には、450万行もの大規模なコードベースへの貢献も含まれています。例えば、画像圧縮ライブラリ「libwebp」で過去に発見され、iOSのゼロクリック攻撃にも悪用されたバッファオーバーフローの脆弱性（プログラムが確保したメモリ領域を越えてデータが書き込まれる問題）に対して、「-fbounds-safety」という安全なコードアノテーション（特定の情報や設定をコードに追加する印）を適用し、将来的な同種の脆弱性を防止する対策を行っています。
現在、CodeMenderが生成する全ての修正は、人間による最終レビューを経てから公開されています。これは、修正の品質を確実に保ち、オープンソースコミュニティからのフィードバックを慎重に受け止めるためです。Google DeepMindは、今後、重要なオープンソースプロジェクトの管理者と連携を深め、得られたフィードバックを基にCodeMenderを改善していく予定です。最終的には、このCodeMenderを全てのソフトウェア開発者が利用できるツールとしてリリースし、世界中のソフトウェアのセキュリティ向上に貢献することを目指しています。
引用元: https://deepmind.google/discover/blog/introducing-codemender-an-ai-agent-for-code-security/
What Makes 5% of AI Agents Actually Work in Production?AIエージェントを実際に製品として使えるようになるのは、実はたった5%くらいしかないって知っていましたか？この記事では、その成功するAIエージェントが何をしているのか、日本の新人エンジニアさんにもわかりやすく解説してくれています。
多くの人は、AIの賢さ（モデルの性能）が大事だと思いがちですが、失敗のほとんどは、そのAIを支える「周辺システム」（コンテキスト設計、セキュリティ、メモリ管理など）がうまくできていないのが原因だそうです。
「文脈（コンテキスト）」の重要性AIエージェントにとって、「モデルは土壌、コンテキストは種」という言葉があります。つまり、どんなに高性能なモデル（土壌）があっても、適切な「文脈情報（コンテキスト、種）」を与えなければ、良い結果は生まれないということです。最近よく聞くRAG（Retrieval-Augmented Generation）という技術が重要ですが、ただ情報を集めるだけではダメ。必要な情報だけを厳選し、正しく整理し、検証する「高度なコンテキストエンジニアリング」が求められます。例えば、関連性の高い情報だけを選んだり（選択的コンテキストプルーニング）、データの種類や鮮度をチェックしたり、どの情報がAIの回答に影響したかを追跡できるようにしたりします。
セキュリティと信頼性の確保本番環境でAIを使う上で、特にエンタープライズ（企業）環境では、セキュリティやアクセス権限の管理が非常に重要です。誰がどんな情報にアクセスできるか、AIの出力がどの情報源に基づいているかを追跡できる「リネージ」の確保が必須です。また、同じ質問をしても、社員の役職や権限によってAIの回答が変わるようにする仕組みも必要になります。そして何よりも「信頼」が重要です。AIがアシスタントとして人間をサポートし、人間が最終的な判断を下す「Human-in-the-loop（人間が介入する）」設計が、ユーザーからの信頼を得る上で欠かせません。
メモリ管理と複数モデルの使い分けAIエージェントは、過去のやり取りやユーザーの好みを覚える「メモリ」を持つことで、より賢くパーソナルな体験を提供できます。しかし、そのメモリをどう管理するか（ユーザーごとに、チームごとに、組織ごとに）、またプライバシーをどう守るかは難しい課題です。また、すべてのタスクに同じ高性能なAIモデルを使うのは効率的ではありません。簡単な質問には高速で安価なモデルを、複雑な分析には高性能なモデルを使うなど、タスクに応じて複数のモデルを賢く使い分ける「モデルオーケストレーション」の技術も進化しています。
自然言語とGUIの適切な使い分けAIエージェントと対話する際に、何でもかんでもチャット形式が良いわけではありません。例えば、BIツールのような複雑なデータ分析では、自然言語で質問するときの学習コストを減らせます。しかし、一度答えが出たら、チャートの種類を変えるなどの微調整はGUI（グラフィカルユーザーインターフェース）で行いたいものです。ユーザーのニーズに合わせて、自然言語とGUIを組み合わせた設計が重要になります。
これからのエンジニアに求められることこれからのAI開発では、単にモデルの性能を追求するだけでなく、「質の高いコンテキスト」「適切なメモリ設計」「信頼性の高いオーケストレーション」「ユーザーが信頼できるUX」といった周辺要素が、AIエージェントの成功を左右する重要なポイントになります。新人エンジニアの皆さんも、ぜひこれらの要素を意識して、これからのAI開発に取り組んでみてください。
引用元: https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually
Not Another Workflow BuilderLangChainチームは、これまでビジュアルワークフロービルダーの開発に積極的ではありませんでした。最近OpenAIが同様のツールを発表したことを受け、LangChainがなぜこの道を選ばなかったのか、そして今後何に注力していくのかを解説しています。
ノーコードのワークフロービルダーは、主に非技術者がAIエージェントを構築できるようにすることを目的としています。これは、技術者不足の解消や、非技術者が持つ具体的な業務知識をAIシステム開発に活かすためです。
ここで重要なのは「ワークフロー」と「エージェント」の違いです。AIエージェントは「LLMがツールを繰り返し使って目標を達成するシステム」と定義されます。
ワークフローは、決められた手順に沿って動くため「予測しやすく」安定していますが、柔軟性（自律性）は低いです。複雑な分岐処理などを「グラフ」として視覚的に表現します。 エージェントは、自律的に判断して行動するため「柔軟性」が高い反面、結果を予測しにくい側面があります。その複雑なロジックは、自然言語の「プロンプト」に抽象化されます。どちらも目指すのは「期待通りに動く信頼性の高いシステム」を構築することです。筆者は、OpenAIのAgentKitや既存の類似ツールは、実際には「ビジュアルワークフロービルダー」であり、真の「エージェントビルダー」ではないと指摘します。ビジュアルワークフロービルダーには、以下の課題があります。
参入障壁が高い: 非技術者にとって、ノードとエッジを使いこなすのは依然として難しく、決して簡単に使えるわけではありません。 複雑なタスクに対応しにくい: ある程度の複雑さを超えると、ノードとエッジが画面上でごちゃごちゃになり、管理が非常に困難になります。では、どうすれば「信頼性の高いLLMシステム」を作れるのでしょうか。筆者は問題の複雑度に応じて、最適なアプローチがあると考えます。
高複雑度: 多くの分岐や並行処理が必要な複雑なシステムには、コードによるワークフロー（LangGraphなど）が最も適しています。これまでは専門知識が必要でしたが、AIによるコード生成技術の進化により、この障壁は低くなっていくでしょう。 低複雑度: 比較的シンプルな問題であれば、プロンプトとツールを組み合わせた「ノーコードエージェント」で十分な性能を発揮できるようになってきました。AIモデルの性能向上に伴い、解決できる問題の範囲はさらに広がると予想されます。このように、ビジュアルワークフロービルダーは、シンプルな問題解決ではノーコードエージェントに、複雑な問題解決ではコードによるワークフローに、それぞれ優位性を奪われる「挟み撃ち」の状態にあると筆者は主張します。
LangChainが考える、今後注目すべき課題は以下の2点です。
ノーコードで「信頼性の高い真のエージェント」を簡単に作る方法: ビジュアルワークフローではなく、よりシンプルで効果的なエージェントの作成方法。 LLMを活用したワークフローやエージェントを生成する「コード生成AI」の性能向上: AIが自動でコードを書く能力を高め、より複雑なシステム開発のハードルを下げる。LangChainは、既存のノーコードワークフロービルダーを評価しつつも、より本質的なAIシステムの開発手法に焦点を当てていることがわかります。
引用元: https://blog.langchain.com/not-another-workflow-builder/
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク Introducing AgentKit
OpenAIが、AIエージェント（特定のタスクを自律的に実行するAI）の開発をもっと簡単で効率的にするための新しいツールキット「AgentKit」を発表しました。これまでは、AIエージェントを作るには、たくさんの異なるツールを組み合わせて使ったり、エージェントの性能評価を手動で行ったりと、開発者に大きな負担がかかっていました。AgentKitは、こうした課題を解決し、エージェントの設計からデプロイ、性能改善までを一貫してサポートする、まさに「エージェント開発のためのオールインワンツール」です。
AgentKitの主な機能は以下の3つです。
Agent Builder (エージェントビルダー):これは、複数のAIエージェントが連携して動く「ワークフロー」（処理の流れ）を、まるでフローチャートを描くように視覚的に作れるツールです。ドラッグ＆ドロップでノード（処理の塊）を繋ぎ、エージェントの動きを直感的に設計できます。複雑なエージェントの処理も一目でわかるようになるため、開発チームやビジネス側の関係者みんなで理解しやすくなります。テスト実行やバージョン管理もできるので、試行錯誤しながら素早く改善を進められます。実際に日本の「LY Corporation」でも、わずか2時間足らずでワークアシスタントエージェントを構築できたと紹介されています。
Connector Registry (コネクターレジストリ):エージェントが外部のデータソース（Dropbox、Google Drive、Sharepointなど）や、他のツールと連携するための接続設定を、一元的に管理できる場所です。企業内で多くのエージェントが様々なデータにアクセスする場合でも、管理者がすべての接続をまとめて把握・管理できるため、データ連携がよりスムーズかつ安全になります。
ChatKit (チャットキット):エージェントとユーザーが会話するための「チャットUI」（ユーザーインターフェース）を、あなたのアプリやウェブサイトに簡単に組み込めるツールです。チャット画面のデザインや、エージェントの応答をリアルタイムで表示するといった機能の実装は意外と手間がかかるものですが、ChatKitを使えば、手間をかけずに製品に馴染むチャット機能を素早く追加できます。
さらに、AgentKitには、開発したエージェントの性能を評価し、改善するための強力な機能も加わりました。例えば、「Evals」という評価ツールでは、データセットを使ってエージェントの動作を自動で評価したり、より良いプロンプト（AIへの指示文）を自動で生成したりできるようになります。これにより、エージェントの信頼性や性能を客観的に測り、継続的に向上させることが可能になります。
これらのツールは、AIエージェント開発における「複雑さ」や「手間」を大きく削減してくれるでしょう。新人エンジニアの皆さんも、AgentKitを活用することで、より効率的かつ確実に、革新的なAIアプリケーション開発に挑戦できるようになります。
引用元: https://openai.com/index/introducing-agentkit
LLM用宣言的プログラミング言語 DSPyこの記事では、LLM（大規模言語モデル）を使ったアプリケーション開発をもっと簡単で効率的にする新しい技術「DSPy」について、新人エンジニアの方にも分かりやすく解説しています。DSPyは「Declarative Self-improving Python」の略で、特に「宣言的（Declarative）」という特徴が大きなポイントです。
これまでのLLMアプリケーション開発では、OpenAIのAPIなどを直接使う場合、LLMに与える指示文（プロンプト）を細かく書いたり、状況に合わせて複数のプロンプトを使い分けたりする必要がありました。例えば、足し算のようなシンプルなタスクでも、プロンプトの作成や管理、エラー対応、複雑な処理の組み込みなど、開発者が一つ一つコードで記述する必要があり、これがかなりの手間でした。
DSPyのすごいところは、このプロンプト作成や管理の「手間」を劇的に減らせる点にあります。「宣言的」というのは、「どうやって動かすか」という具体的な手順ではなく、「何をしたいか」という目的だけを記述するアプローチのことです。たとえば、これまでは「〇〇たす△△というプロンプトをLLMに送り、その結果を受け取る」と書いていた部分を、DSPyでは「num1とnum2という入力から、その和（sum）を出力してほしい」と宣言するだけで、LLMへの具体的な指示文（プロンプト）はDSPyが自動的に生成・調整してくれます。
実際のコード例を見ると、OpenAIのAPIを直接使った場合に数行必要だった記述が、DSPyではdspy.Predict('num1, num2 -> sum')のようにたった1行で済みます。これにより、開発者はプロンプトの細かい文言に頭を悩ませることなく、LLMに解決させたいタスクの入力と出力の形だけを定義すればよくなります。また、dspy.Signatureを使って、和だけでなく差や文字列の連結など、複数の出力を同時に得るような複雑なタスクも、明確な形で定義できます。
さらに、DSPyには「CoT（Chain Of Thought）」という、LLMが段階的に思考して答えを導き出す機能も簡単に組み込めます。これは、複雑な問題に対してLLMが「なぜその結論に至ったか」という理由（reasoning）も含めて出力してくれるもので、高度な問題解決に役立ちます。DSPyではdspy.ChainOfThoughtを使うだけで、こうした多段階の推論も宣言的に記述できます。
このようにDSPyは、LLMアプリケーション開発において、開発者が「何をさせたいか」に集中できるよう、プロンプトの設計や調整といった手間のかかる作業を自動化してくれる画期的なツールです。今後は、LLMの振る舞いを評価し、プロンプトを自動で最適化する「プロンプトチューニング」の機能も活用され、LLM開発をさらにシンプルで強力なものに変えていくことが期待されています。
引用元: https://zenn.dev/cybernetics/articles/f879e10b53c2db
AMD and OpenAI announce strategic partnership to deploy 6 gigawatts of AMD GPUs皆さん、こんにちは！今回は、テクノロジー業界で非常に大きなニュースが飛び込んできたので、要点を分かりやすく解説します。半導体大手AMDと、チャットAI「ChatGPT」で有名なOpenAIが、今後数年間にわたる大規模な戦略的パートナーシップを発表しました。これは、AIの進化をさらに加速させるための重要な一歩となります。
● 超大規模なAIインフラ計画今回の発表の最大のポイントは、OpenAIが次世代のAIインフラのために、なんと「6ギガワット」ものAMD製GPU（グラフィック処理装置）を導入するという点です。ギガワットは電力の単位ですが、これはAIを動かすための計算能力が途方もなく大規模であることを示しています。私たちが普段使っているPCのGPUが数Wから数百W程度であることを考えると、その規模の巨大さが想像できるでしょう。
● なぜGPUがAIに不可欠なのか？AI、特に「生成AI」と呼ばれるChatGPTのような技術は、膨大なデータを高速に処理する計算能力が不可欠です。GPUは、この種類の計算を非常に得意としており、AIの「脳」とも言える役割を担っています。OpenAIは、AMDの高性能GPUを活用することで、よりパワフルで高度なAIモデルを開発し、私たちが利用できるAIサービスの可能性を広げようとしています。
● 具体的な導入スケジュールと今後の展開この計画は2026年後半から始まり、まずは1ギガワット分のAMD Instinct MI450シリーズGPUが導入されます。MI450シリーズは、AIや高性能計算に特化したAMDの最新GPUです。この提携は単に製品を供給するだけでなく、両社が技術的な専門知識を共有し、協力してAI向けハードウェアやソフトウェアの最適化を進める、まさに二人三脚の取り組みです。これまでもMI300XやMI350Xシリーズで協力してきましたが、今回の提携でその関係はさらに深まります。
● 両社のWin-Winな関係AMDにとっては、OpenAIという最先端のAI開発企業に大規模にGPUを供給することで、市場における存在感をさらに高めることができます。OpenAIにとっては、AI開発に必要な計算能力を安定して、かつ先進的な技術で確保できるという大きなメリットがあります。このパートナーシップは、単なるビジネス上の取引を超え、AI業界全体の成長と発展に貢献するものと期待されています。
AMDのCEOリサ・スー氏も、OpenAIのCEOサム・アルトマン氏も、この提携がAIの可能性を最大限に引き出し、その恩恵をより早く世界中に届けるための重要なステップだとコメントしています。新人エンジニアの皆さんにとっては、AIインフラがいかに巨大なもので、その裏側でどのような企業が協力し合って未来を築いているのかを知る良い機会になるでしょう。
引用元: https://openai.com/index/openai-amd-strategic-partnership
最近の学生が知らなそうなIT知識このユニークな記事では、今の学生には馴染みがないかもしれない、懐かしいIT知識が紹介されています。例えば、液晶のドット抜けやテレホーダイ、CD-Rといった言葉に、「あとひとつは？」と読者へ問いかけ。コメント欄にはフロッピーディスクやInternet Explorer、MO、Y2Kなど、ベテランエンジニアが思わず「あったあった！」と頷くような用語が多数寄せられています。昔のIT技術や文化を知ることで、先輩たちの歩んだ歴史を感じられる、クスっと笑顔になれる楽しい記事です。
引用元: https://anond.hatelabo.jp/20251006203201
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク Managing context on the Claude Developer Platform
Anthropicは、AIエージェントが長期かつ複雑なタスクをより効率的に実行できるよう、「コンテキスト管理」の新機能をClaude Developer Platformに導入しました。これは、新人エンジニアの皆さんにとって、これからのAI開発を理解する上で非常に重要なアップデートです。
従来のAIエージェントは、一時記憶（コンテキストウィンドウ）の限界から、長時間のタスクで情報を見失ったり、性能が落ちたりする課題がありました。この根本的な問題を解決するため、主に二つの新機能が提供されます。
コンテキスト編集（Context editing）：トークン制限に近づくと、古いツール結果など不要な情報を自動でコンテキストから削除します。これにより、エージェントは必要な情報に集中し、より長くタスクを実行できるようになり、パフォーマンスも向上します。
メモリツール（Memory tool）：重要な情報をコンテキスト外にファイルとして永続的に保存し、必要に応じて参照できる「長期記憶」機能です。セッションを跨いで知識を蓄積し、プロジェクトの状態維持が可能。データ保存は開発者が制御します。
これらの機能は、最新モデルClaude Sonnet 4.5と組み合わせることで、トークン使用状況を意識した効率的なコンテキスト管理が可能となり、エージェントの能力を最大限に引き出します。
この進化により、AIエージェントは大規模なコード処理、多数のドキュメント分析、長期データ処理など、これまで困難だった複雑なタスクを高精度でこなせるようになります。
実際の評価では、コンテキスト管理機能の併用により、エージェントのパフォーマンスが39%向上。トークン消費量を84%削減し、コンテキスト枯渇によるタスク失敗も劇的に減少したと報告されています。
これらの画期的な機能は現在、公開ベータ版としてClaude Developer Platformで利用可能です。ぜひ今後のAI開発に活用を検討してみてください。
引用元: https://www.anthropic.com/news/context-management
95%以上をLLMが実装。『みらいまる見え政治資金』を45日で完成させた、AIネイティブな開発手法についてご紹介この記事では、チームみらいが開発した「みらいまる見え政治資金」プロジェクトにおいて、コードの95%以上をLLM（大規模言語モデル）に実装させ、約45日という短期間で中規模アプリケーションを完成させた、AIネイティブな開発手法が紹介されています。公開後約2日で20万PVを超える反響を呼びました。
この開発では、LLMの特性を最大限に活かすため、プロジェクト全体の設計が非常に重要視されました。具体的には、エンドユーザー向け画面、管理画面、共有オブジェクトの3パッケージに分けるモノレポ構成を採用。これにより、LLMが見通しを保ちやすく、必要に応じてパッケージ間参照も容易になるよう工夫しました。Next.js特有のクライアントサイドとサーバーサイドの混同を防ぐため、ディレクトリで明確に分け、「server-only」といったルールも適用。サーバー処理も厳格なレイヤー分けを行い、LLMは面倒がらないため、ルールに従って見通しの良い構造を維持しました。
実装段階では、主にClaude Codeを使い、プロジェクトの設計・実装ルールを「CLAUDE.md」にまとめ、LLMに厳守させました。複雑な機能は、まず設計ドキュメントを作成させてから実装を開始しました。さらに、Figmaのデータを直接読み取れるMCPを活用し、デザインの実装もLLMに任せました。指示を細かく分割することが成功の鍵です。
AIが書いたコードの品質を担保するためには、人間によるレビューが不可欠です。この記事では、個々のロジックよりレイヤー責務の確認を重視し、重要な処理にはユニットテストをLLMに書かせ効率的に品質を保証しました。Biomeを用いた自動フォーマットやCIでのチェックを導入し、開発を効率化しました。
最終的に、ほぼ全ての領域をLLMに任せることができ、「100%実装も可能」だと述べられています。LLMの「忍耐強さ」を活かし、厳密なルールを例外なく適用することが、開発スピード向上につながると結論付けています。ただし、この手法はフルスクラッチ、Next.js+TypeScript、中規模アプリといった特定の条件下で特に効果を発揮します。新人エンジニアにとって、AIと協働する未来の可能性を感じさせる貴重な事例です。
引用元: https://note.com/jujunjun110/n/na653d4120d7e
J-RAGBench：日本企業でRAGするときの落とし穴とは皆さん、こんにちは！今回は、RAG（Retrieval-Augmented Generation）という技術を日本企業で使う時にどんな問題が起こりやすいのか、そして最適なAIモデルを選ぶにはどうすればいいのかを明らかにする「J-RAGBench」という新しい評価ツールについて紹介します。
RAGは、検索した情報に基づいてAI（大規模言語モデル、LLM）が回答を作る技術です。最近は様々なAIモデルが登場していますが、実際のビジネス現場でRAGを使うには、単に情報を検索するだけでなく、複数の情報をまとめて理解したり、そこから推論したり、表形式のデータを正確に読んだり、さらには情報が見つからない時に「分かりません」と適切に断る能力など、非常に複雑な能力がAIに求められます。
しかし、これまでのAI評価ツール（ベンチマーク）では、これらの複雑な能力を十分に測ることができませんでした。そこで、株式会社neoAIの研究開発チームが、金融や製造業といった実際の業界でRAGを導入する中で直面した「落とし穴」を元に、新しい日本語RAGベンチマーク「J-RAGBench」を開発しました。
J-RAGBenchの主な特徴は以下の通りです。
評価観点の再定義：実際のビジネスシーンでAIに求められる能力を「情報統合」「推論」「論理条件の解釈」「表形式の解釈」「回答拒否」の5つのカテゴリに体系化しています。 複数の能力を同時に評価：現実の難しい問題では複数の能力が同時に必要になるため、高難易度な複合問題を多く含んでいます。 架空シナリオの採用：AIが元々持つ知識に頼らず、与えられた情報だけを正確に読み取る純粋な外部文書参照能力を評価するために、架空の状況を設定した問題を採用しています。J-RAGBenchを使って、様々なAIモデル（API提供モデルやオープンウェイトモデル）を評価したところ、各モデルの得意・不得意が明確になりました。
GPT-5は、どのカテゴリにおいてもバランスよく高いスコアを示しました。 o3やo4 miniといったモデルは、情報からの推論は得意ですが、情報がないのにそれらしい嘘の情報を話してしまう「ハルシネーション（幻覚）」を起こしやすい傾向が見られました。 Claude Sonnet 4は、情報がないときに適切に「回答できません」と断る能力が非常に高く、ハルシネーションを起こしにくい「高信頼型」でしたが、他の能力はやや劣る結果でした。また、詳細な分析では、AIが情報の粒度が不均一な場合に誤答したり、数値計算や複雑な表の解釈でミスしたり、根拠となる情報がないにも関わらずハルシネーションを起こしてしまうケースが確認されました。特に、小さなモデルほど、マルチホップ推論や回答拒否の能力が低い傾向にありました。
これらの結果は、RAGシステムを実際に運用する際に、どのような用途で利用するか（例えば、バランスの取れた回答を求めるか、信頼性を最優先するか、など）に応じて、適切なAIモデルを選ぶことの重要性を示しています。J-RAGBenchは、RAGのAIモデル選定において、新人エンジニアの皆さんにとって貴重な判断材料となるでしょう。
引用元: https://zenn.dev/neoai/articles/0998f81c39a583
ガストで昼間からビール飲んでるおじさんが配膳ロボットにお触りしてて、ロボットの方も「くすぐったいにゃん」とか言ってた… 何なんだこの空間はガストの猫型配膳ロボット「BellaBot Pro」が、お客さんに触られると「くすぐったいにゃん」と可愛く反応する様子が話題になっています。昼間からビールを楽しむお客さんがロボットと触れ合う光景は、AIやロボット技術が私たちの日常に自然に溶け込み、予想外の面白いコミュニケーションを生み出していることを示しています。新人エンジニアの皆さんも、こんなクスッと笑える瞬間から、人とテクノロジーの新しい関わり方に注目してみませんか。
引用元: https://togetter.com/li/2611523
お便り投稿フォームVOICEVOX:春日部つむぎ
-
youtube版(スライド付き)関連リンク Practical LLM Security Advice from the NVIDIA AI Red Team
NVIDIAのAIレッドチームが、LLM（大規模言語モデル）アプリケーション開発で直面する主要なセキュリティリスクと、その対策について実践的なアドバイスを公開しました。新人エンジニアの皆さんが、安全なLLMシステムを構築するために知っておくべき3つの重要なポイントを分かりやすく解説します。
1. LLM生成コードの実行によるリモートコード実行（RCE）LLMが生成したコードを、隔離なしに実行することは非常に危険です。execやevalのような関数を使うと、悪意あるプロンプト（指示）で不正なコードが生成・実行され、「リモートコード実行（RCE）」につながり、アプリケーション全体の乗っ取りリスクが生じます。対策: LLM生成コードの直接実行は避けましょう。動的なコード実行が必要な場合は、WebAssemblyのような厳重に隔離された「サンドボックス」環境で実行が必須です。理想的には、LLMの応答から意図を解析し、許可された安全な機能のみを呼び出す仕組みを構築します。
2. RAGデータソースのアクセス制御の不備RAG（Retrieval-Augmented Generation）はLLMに外部情報を提供しますが、ここにもリスクがあります。
データ漏洩: ユーザーごとのアクセス権限が不適切だと、機密情報が誤って他のユーザーに見えてしまう可能性があります。 間接的プロンプトインジェクション: RAGデータストアへの書き込み権限が広すぎると、悪意あるデータが注入され、LLMの応答が操作される危険性があります。対策: 元データのアクセス権限をRAGシステムにも正確に反映し、厳しく管理してください。データストアへの書き込みアクセスは限定し、信頼できるデータのみが追加されるようにしましょう。出力される情報が質問の意図に合っているか「ガードレール」でチェックすることも有効です。3. LLM出力によるアクティブコンテンツのレンダリングLLMの出力にMarkdownやHTMLのようなアクティブコンテンツ（リンクや画像など）が含まれる場合、ユーザーが気づかないうちにブラウザを通じて機密データが攻撃者のサーバーへ送信される可能性があります。これは「データ流出」につながる重大な問題です。対策:
画像の読み込み元を、許可された「安全なサイト」に限定する「コンテンツセキュリティポリシー（CSP）」を設定します。 リンクは、クリック前にユーザーがURL全体を確認できるようにするか、手動でコピー＆ペーストが必要な「非アクティブ」な形式にします。 LLMの出力に含まれるアクティブコンテンツは、表示する前に必ず「サニタイズ（無害化）」し、悪意ある記述を取り除くことが極めて重要です。これらのセキュリティ対策を開発の早い段階から取り入れることで、皆さんのLLMアプリケーションはより安全で信頼性の高いものになります。ぜひ、日々の開発に活かしてください。
引用元: https://developer.nvidia.com/blog/practical-llm-security-advice-from-the-nvidia-ai-red-team/
RubyLLM が Ruby に洗練された AI 統合をもたらし、開発者エクスペリエンスの議論を巻き起こす新人エンジニアの皆さん、こんにちは！今回は、Rubyというプログラミング言語でAI（人工知能）を扱うための新しいライブラリ「RubyLLM」について、わかりやすく解説します。このライブラリは、開発者がAIをもっと楽しく、スムーズに使えるようにすることを目指しており、開発者の間で大きな話題になっています。
RubyLLMの最大の特徴は、何と言っても「開発者エクスペリエンス（DX）」の良さです。DXとは、開発者がどれだけ快適に、ストレスなく開発できるかを示す言葉ですね。RubyLLMは、まるで普段の会話のように、自然で読みやすいコードでAIとやり取りができるように設計されています。例えば、OpenAIやGoogleのGeminiといった様々なAIモデルがある中で、それぞれバラバラのやり方でコードを書く必要がなく、RubyLLMを使えば統一されたシンプルな方法で扱えるんです。これは、複雑なAI機能を実装する際の「困った！」を減らし、「サクサク開発できる！」という喜びをくれるでしょう。他のAIライブラリと比べて、「RubyLLMはまるで新鮮な風だ」と評価する声も上がっています。Rubyの生みの親であるまつもとゆきひろさんが掲げる「開発者の幸福」という考え方が、このライブラリにもしっかり反映されていると言えますね。
もちろん、良い点ばかりではありません。一部の開発者からは、Rubyの並行処理（複数のタスクを同時に進める方法）について懸念が示されています。AIモデルにたくさんのリクエストを同時に送るような場合、Rubyの現在の仕組みでは、AIからの応答を待っている間、他の処理が一時的に止まってしまう可能性があり、これがパフォーマンス（処理速度）に影響するかもしれない、という議論です。しかし、ライブラリの作者もこの課題を認識しており、将来のアップデートでより効率的な処理方法を導入することを検討しているようです。これは、「使いやすさ」と「処理速度」という、ソフトウェア開発における永遠のトレードオフを考える良い機会にもなりますね。
「AI時代にRubyってどうなの？」という疑問を持つ人もいるかもしれません。プログラミング言語の人気ランキングでは、Rubyが以前ほど上位ではないという見方もあります。しかし、RubyLLMの登場は、AI分野でのRubyの可能性を改めて示しています。多くのAIを使ったアプリケーションでは、処理のボトルネック（一番時間がかかる部分）は、実はプログラミング言語そのものよりも、AIモデルが回答を生成する時間であることがほとんどです。実際に、Ruby on RailsのようなRuby製のフレームワークは、その予測可能な構造と整理されたルールのおかげで、AIがコードを理解したり修正したりするのに適している、という意見もあります。
RubyLLMは、最大限のパフォーマンスを追求する場面よりも、可読性が高く、保守しやすいコードを書きたい開発者にとって、非常に魅力的な選択肢となるでしょう。AI技術が日々進化する中で、既存の言語がどのように新しい技術と融合していくかを示す、興味深い事例と言えます。このライブラリを通じて、皆さんもAI開発の楽しさを体験してみてください。
引用元: https://biggo.jp/news/202503170934_RubyLLM_Elegant_AI_Integration
【書評】『AIエージェント開発/運用入門』これからAIエージェント開発を始めたいエンジニアへこの書評では、AIエージェント開発の最前線を網羅した書籍『AIエージェント開発/運用入門[生成AI深掘りガイド]』が紹介されています。これからAIエージェント開発を始めたいと考えている新人エンジニアの方や、すでにLangGraphを使っているけれど他のフレームワークも知りたい、忙しい中で体系的に知識をキャッチアップしたい方に特におすすめの一冊です。
本書は全8章で構成されており、まずLLM（大規模言語モデル）とAIエージェントの基本的な知識からスタートします。その後、LangGraph、Mastra、Strands Agentといった主要な開発フレームワークを使った実践的なハンズオンを通して、実際に手を動かしながら学べます。さらに、マルチエージェントやエージェンティックワークフローなどの応用的なアーキテクチャ、開発・運用に不可欠なLLMOps（MLOpsのLLM版）、そしてAIエージェントの安全性や評価方法まで、幅広いテーマが網羅されています。2025年秋時点での最新情報が盛り込まれており、この分野のトレンドを掴む上で非常に役立つでしょう。
特に注目したいのは、以下の2つの章です。
第5章「MastraでフルスタックのAIエージェントアプリを作ろう」:Mastraというツールを使って、Webアプリケーションの要件定義からフロントエンド、バックエンド、インフラ、さらにはAWS AmplifyへのデプロイやCognitoによる認証認可まで、AIエージェントアプリ開発の一連の流れを「フルスタック」で体験できます。実際の開発現場で役立つ実践的な知識が、丁寧な解説と豊富な図解で分かりやすく学べるため、一つのアプリを作り上げる達成感を味わいながら、自信をつけることができるはずです。
第6章「応用的なAIエージェント開発に挑戦しよう」:AIエージェントの設計思想、例えばエージェントの「自律性」と「制御性」のバランスの取り方や、シングルエージェントとマルチエージェントそれぞれのメリット・デメリットといった重要な考慮事項を学べます。さらに、Amazon Bedrock AgentCoreやAWSが提供するOSSのStrands Agentsを使ったマルチエージェント構築のハンズオンも体験でき、最新のツールを使った応用的な開発に挑戦できる貴重な機会となるでしょう。
本書は、多くのフレームワークを使ったAIエージェントやワークフロー開発、LLMOpsについて、手を動かしながら深く理解するための手助けとなる一冊です。これからのAIエンジニアとしてのキャリアを築く上で、自身の環境に最適なAIエージェント開発手法を見つけるための強力なガイドになること間違いなしです。
引用元: https://qiita.com/hedgehog051/items/ca64f9958addebc58cf9
お便り投稿フォームVOICEVOX:ずんだもん
-
youtube版(スライド付き)関連リンク 未だにAIを「統計的に次の単語を予測しているに過ぎない」って言ってる人いるAIの動作原理に関する議論：単なる「次の単語予測」を超えて
この記事では、最新のAI、特に大規模言語モデル（LLM）の能力を「統計的に次の単語を予測しているに過ぎない」と解釈することへの疑問が提起されています。筆者は、この認識では現在のAIが示す高度な成果（まるで意味を理解し、推論しているかのような振る舞い）を説明しきれないと感じています。
AI自身の説明と本質筆者がAI自身にその仕組みを尋ねたところ、「言語と世界知識を統計的に圧縮した汎用パターン認識器」や、「次に来る単語を予測するために、言語と世界知識を高次元ベクトル空間に圧縮し、そこから最適な次語を取り出すパターン認識器」という回答が得られました。これは、単なる「予測変換」とは異なり、膨大な情報を高次元の空間で効率的に処理し、その結果として人間らしい応答や推論に近い能力を発揮していることを示唆しています。
「統計的予測」という言葉の裏側「統計的に次の単語を予測する」という表現は、AIの基本的な動作原理を指しますが、その言葉だけを聞くと、まるで単純な辞書引きや確率計算のように誤解されがちです。しかし、実際のLLMは、私たちが話す言葉や世界の知識を数値データ（ベクトル）として「高次元ベクトル空間」に配置し、その膨大なデータのパターンから最も適切な応答を生成しています。この複雑なプロセスによって、AIは文脈を理解し、質問に答え、時にはクリエイティブな文章を生み出すことが可能になっているのです。
新人エンジニアへのメッセージこの議論は、AIの核心的な理解を深める上で非常に重要です。AIが「統計的な予測」に基づいていることは事実ですが、その「統計的な予測」がどのような仕組みで、どれほど複雑な情報処理を経て行われているかを理解することが大切です。コメント欄でも、「人間も統計的な予測をしているのではないか」「AIに真の推論能力はない」など、様々な視点からの活発な議論が展開されています。これらの多角的な意見に触れることで、AIの可能性と限界、そして人間との違いについて深く考えるきっかけとなるでしょう。
引用元: https://anond.hatelabo.jp/20250930225212
Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code「Comprehension Debt: The Ticking Time Bomb of LLM-Generated Code（理解負債：LLMが生成するコードの時限爆弾）」というこの記事は、近年のAI、特に大規模言語モデル（LLM）が生成するコードが、開発現場にもたらす新たな課題に警鐘を鳴らしています。
新人エンジニアの皆さんも、もしかしたら「こんなコード、誰が書いたんだろう…」と、過去のレガシーコードの理解に苦しんだ経験があるかもしれません。昔のコードを安全に修正したり、新しい機能を追加したりするには、まずそのコードが「何をしているのか」「なぜそのように実装されているのか」を深く理解する必要があります。これは開発者にとって昔からの課題です。
しかし、LLMの登場により、この「理解の課題」がとてつもない規模で拡大しつつあると著者は指摘します。LLMは驚異的なスピードで大量のコードを生成するため、開発チームは自分たちが書いたわけではない、誰も読んでいないコードを大量に抱え込むリスクに直面しています。著者はこの現象を「理解負債（Comprehension Debt）」と呼んでいます。これは、後からそのコードを理解し、修正するために必要となる追加の時間のことを指します。
品質を重視するチームでは、LLMが生成したコードでも、人間のエンジニアが時間をかけてレビューし、理解し、必要であれば手直ししてからリポジトリにコミットします。これは非常に大切なことですが、結果としてLLMが提供する「高速なコード生成」のメリットが相殺されてしまいがちです。
一方で、スピードを優先するあまり、LLMが生成したコードを十分にレビューせず、また適切なテストも行わずにそのままシステムに組み込んでしまうチームも少なくありません。このような状況が蔓延すると、プロジェクトの奥深くには「誰もその中身を正確に知らない、けれどシステムを動かす上で重要なコード」がまるで時限爆弾のように蓄積されていくことになります。
「AIに直してもらえばいいじゃないか」と考える人もいるかもしれません。しかし、LLMを使ってコードを修正しようとすると、時には「Doom loops（無限ループ）」と呼ばれる、何度指示しても問題が解決せず、堂々巡りになるような状況に陥ることもあります。結局のところ、多くの場面で人間のエンジニアが自らコードを修正する必要が出てくるのです。その時、誰も理解していないコードを解読することに、莫大な「理解負債」の返済時間がかかることになります。
この記事は、LLMを開発に活用する際に、単にコード生成のスピードだけでなく、その後の保守性や可読性、そしてチーム全体の「理解」という観点から、コードの品質に深く目を向けることの重要性を教えてくれます。新人の皆さんにとっても、LLMを使う際には、生成されたコードを鵜呑みにせず、必ず内容を吟味し、理解しようと努める姿勢が今後ますます重要になるでしょう。この「理解負債」を増やさないために、私たちエンジニアがどうLLMと向き合うべきか、深く考えるきっかけとなる記事です。
引用元: https://codemanship.wordpress.com/2025/09/30/comprehension-debt-the-ticking-time-bomb-of-llm-generated-code/
Sora 2 is here皆さん、こんにちは！OpenAIから、最新の動画・音声生成AIモデル「Sora 2」が発表されました。これは、2024年2月に登場した初代Soraが「動画生成が初めて実用的になり始めた画期的な一歩」だったのに対し、Sora 2はそこからさらに大きく進化し、「もっと現実的で便利なレベルになった状態」へ飛躍したと位置づけられています。まるで、GPT-1からGPT-3.5への進化に匹敵する、大きな進歩なんです。
Sora 2の最も画期的な点は、動画における物理的な正確さとリアリズムが飛躍的に向上したことです。以前のモデルでは、例えばバスケットボールのシュートが外れても、なぜかゴールに入ってしまうような、現実とは異なる動きが生成されることがありました。しかし、Sora 2では、シュートが外れればボールがバックボードに跳ね返るなど、実際の物理法則に則った動きを忠実に再現できるようになりました。これは、AIが現実世界を深く理解し、シミュレートする能力が高まったことを意味します。
さらに、Sora 2は動画の「制御性」も大きく向上しています。複雑な指示に従って複数のシーンを生成したり、現実的、映画的、アニメといった多様なスタイルで動画を作ったりすることが可能です。音声面でも進化しており、動画に合わせたリアルな背景音、会話、効果音を自動で生成し、まるで本物の映画を見ているかのような臨場感を提供します。
そして、特に注目すべき新機能の一つが「Cameos（カメオ）」です。これは、あなた自身の姿や声をSoraが生成した動画の中に登場させられる機能です。一度短い動画と音声を登録するだけで、Soraが作り出したあらゆるシーンにあなたが「出演」できるようになります。
このSora 2の力を体験できるiOS向けソーシャルアプリ「Sora」も同時にリリースされました。アプリでは、自分や友達のCameosを使って動画を生成したり、友達が作った動画をリミックスしたり、自分だけのSoraフィードを楽しんだりできます。OpenAIは、このアプリを「動画をただ見る（消費）」よりも「自分で作る（創造）」に重点を置いて設計しており、友達との新しいクリエイティブなコミュニケーション手段として期待されています。
OpenAIは、責任ある利用にも非常に力を入れています。ユーザーがフィードの内容を細かくコントロールできる機能や、ティーンエイジャーの保護のための視聴制限、そしてCameosを使った肖像権の完全なコントロール（誰があなたのCameoを使えるか、動画を削除できるかなど）が保証されています。
現在、Sora iOSアプリは米国とカナダで先行リリースされており、日本を含む他の地域にも順次拡大される予定です。最初は無料で利用でき、ChatGPT Proユーザーはより高品質な「Sora 2 Pro」モデルも利用できます。将来的には開発者向けのAPIを通じた提供も計画されています。
Sora 2の登場は、AIが現実世界をシミュレーションし、最終的にはロボットエージェントとして機能する未来へと、私たちをさらに近づける重要な一歩です。OpenAIは、この技術が世界に新たな喜び、創造性、そして人々のつながりをもたらすと期待しています。皆さんもぜひ、Sora 2の新しい創造体験に触れてみてください！
引用元: https://openai.com/index/sora-2
「【至急】ご対応ください」と題したメールに今日入社する人のPCの用意をしてと書かれていた、しかも時刻は8時45分「もうちょっと早く教えてよ」「ドラえもんじゃないんだぞ」入社日朝8時45分、新入社員のPC準備を「至急」依頼されたIT担当者のツイートが話題です。これに「ドラえもんじゃないぞ！」と多くのエンジニアが共感し、PC・アカウント未準備で業務開始が遅れた「あるある」体験談が多数投稿されました。新人エンジニアは、円滑な業務開始のため、IT環境の事前準備の重要性を学ぶ、クスッと笑えるエピソードです。
引用元: https://togetter.com/li/2609936
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク Temporal Workflow で実現する Durable な AI Agent #LayerX_AI_Agent_ブログリレー
この記事は、AI Agentを実際のプロダクトに組み込む際に直面する「長時間実行される処理をいかに安定して動かすか」という課題を、Workflow EngineであるTemporal Workflowを使って解決する方法について、新人エンジニアにも分かりやすく解説しています。
AI Agentとは、与えられた目標に対し、ツールを自律的に使って情報を集めたり、環境に働きかけたりしながらタスクをこなすソフトウェアのことです。例えば、ユーザーの入力に応じて情報を検索し、結果を生成するといった一連の処理を「Agent Loop」と呼びます。
このAgent Loopは、数分から数十分かかる長時間処理になることがよくあります。そのため、途中でネットワークが切れたり、サーバーがダウンしたりすると、処理が中断されてしまい、タスクが完了できないという問題が発生します。また、ツールが何らかの変更を伴う場合、中断された処理を単にやり直すと、データが重複して作成されるなどのバグにつながる恐れもあります。このような問題を解決し、AI Agentの処理を確実に最後まで実行するには、途中で中断されても再開できる「Durable Execution（耐久性のある実行）」を実現する仕組みが必要です。
そこで登場するのが「Temporal Workflow」です。Temporalは、私たちが普段書くようなコードで一連のタスク（Workflow）を定義できる実行エンジンです。AI AgentのAgent Loopにおける「LLM（大規模言語モデル）に処理をさせる」「ツールを実行する」といった個々のステップをTemporalの「Activity」として実行することで、Workflow全体の状態をTemporalが管理し、万が一処理が中断しても、途中から確実に再開できるようになります。
Temporal Workflowを導入することには、いくつかの大きなメリットがあります。
柔軟なタスク実行: AI Agentの処理だけでなく、ファイルアップロード時の前処理や定期実行ジョブなど、様々なバックグラウンドタスクをWorkflowとして組み込めます。 外部からの操作に対応: 稼働中のAgentに対して、ユーザーからのメッセージをリアルタイムで受け取ったり（Signalという仕組み）、人の承認が必要なプロセス（Human-in-the-loop: HITL）を簡単に実装したりできます。これにより、ユーザーとの対話がスムーズになります。 状態管理の簡素化: Workflowの途中の状態をデータベースなどに明示的に保存する必要がなく、あたかもローカル変数のように扱えるため、開発者は複雑な状態管理に頭を悩ませずに済みます。 長時間の待ち状態に対応: 特定の条件が満たされるまで待機したり、排他的に処理を実行したりする機能も標準で備わっており、HITLのような長時間にわたるユーザー操作の待ち受けも安定して行えます。 バージョン管理: 長時間実行されるWorkflowの実装が変わっても、古いバージョンと新しいバージョンが混在しないよう、バージョニング機能がサポートされており、安心してデプロイできます。この記事を通じて、AI Agentをプロダクトで活用するためには、AIや機械学習の専門知識だけでなく、Durable Executionの基盤構築、認証認可、評価、監視など、従来のソフトウェアエンジニアリングにおける多くの挑戦があることがわかります。これらは、新人エンジニアにとっても未来の技術の「当たり前」を共に作り上げる絶好の機会となるでしょう。
引用元: https://zenn.dev/layerx/articles/b5f6cf6e47221e
AIエージェントはSaaSをどう変える？ラクスのR&Dで挑戦した垂直型の可能性2025年、自律的にタスクを計画・実行する「AIエージェント」の登場は、ソフトウェア開発の世界に大きなインパクトを与えています。ラクス社では、この技術を自社サービスに取り入れ、進化させるために、R&D活動で「垂直型AIエージェント」の調査・研究に取り組みました。
AIエージェントは、ユーザーの指示に基づいて動く従来の生成AIやAIアシスタントとは異なり、与えられた目標に対して自ら計画を立て、状況に応じて判断し行動できるAIです。特に「垂直型AIエージェント」は、特定の業界や業務（ドメイン）に特化することで、高い専門性を発揮します。これにより、専門知識が必要な高度な分析や判断の支援、ルールに基づいた定型業務の自動化、大量データからの予測と最適化といった領域で大きな価値を提供できるため、ラクス社は自社SaaSへの導入を現実的に進めるため、この垂直型に注目しました。
R&D活動では、AIエージェントの自律レベルを「Assist（支援）」「Copilot（副操縦士）」「Autonomous（自律型）」の3段階、さらに6つの機能パターンに分類し、導入のイメージを具体化しました。また、LLM Core（大規模言語モデルの核となる部分）やRAG（外部知識を参照して回答を生成する技術）、外部ツール連携など、AIエージェントを構成する8つの主要な技術要素を整理しました。
「楽楽勤怠」サービスでのPoC（概念実証）では、GoogleのAgent Development Kit (ADK) を使ってシフト自動作成機能を実装し、その可能性を探りました。簡単なワークフローであれば比較的容易に実装できることが確認できた一方、入力データが増えると処理速度が遅くなる性能課題や、より複雑なシフト作成には複数のAIエージェントが連携する「マルチエージェント」構成の必要性、そして本番運用に向けたセキュリティや保守性の重要性といったリアルな課題も明らかになりました。
AIエージェントを実際のサービスに導入する際には、「処理が遅い、精度が低い」といった性能の壁、「API利用料が高額になる」というコストの壁、「プロンプトインジェクション攻撃への対処」などのセキュリティの壁が存在します。これらを乗り越えるためには、モデルの最適化、RAGの精度向上、軽量モデルの活用、不適切な入出力を防ぐガードレール機能、人間の確認・介入といった対策が不可欠です。
今回のプロジェクトで得られた貴重な知見は、「垂直型AIエージェント実装ナレッジベース」として社内のGitHub Wikiにまとめられ、全エンジニアがアクセスできるよう公開されました。これにより、各プロダクトへのAIエージェント導入を加速させ、組織全体の技術力向上を目指しています。ラクス社は今後もこのようなR&D活動を続け、最新技術をSaaSサービスに反映させ、お客様に新たな価値を提供していくとしています。
引用元: https://tech-blog.rakus.co.jp/entry/20250930/AIagent
Effective context engineering for AI agentsLLM（大規模言語モデル）を活用した開発では、これまで「プロンプトエンジニアリング」が注目されてきました。これは、LLMに効果的な指示（プロンプト）を与えることで、望む結果を引き出す技術です。しかし、近年では、より高度な「コンテキストエンジニアリング」が重要視されています。
コンテキストエンジニアリングとは、LLMが推論に利用できる「コンテキスト（文脈や情報）」全体を最適に管理する技術のことです。単にプロンプトの言葉を選ぶだけでなく、システムプロンプト、ツール、過去の会話履歴、外部データなど、LLMに与えるあらゆる情報を、望ましい挙動を安定して引き出すためにどのように構成すべきかを考えます。
なぜコンテキストエンジニアリングが重要なのでしょうか？LLMは、人間と同じように、与えられる情報量が増えすぎると集中力が散漫になり、重要な情報を見落としたり、記憶力が低下したりする「コンテキスト腐敗（Context Rot）」という現象が起こります。これは、LLMの基礎となっているTransformerという仕組みの特性によるもので、コンテキストの長さが長くなるほど、処理に必要な計算量が爆発的に増え、パフォーマンスが低下する傾向があるためです。つまり、LLMにとってコンテキストは有限で貴重なリソースなのです。
効果的なコンテキストを構築するためには、以下の要素が重要です。
システムプロンプト: LLMへの指示は、具体的すぎず、かといって曖昧すぎない「適切な抽象度」で、明確かつ簡潔に記述します。情報のセクション分け（例：XMLタグやMarkdownヘッダー）も効果的です。 ツール: LLMが外部と連携して情報を取得したり操作したりするためのツールは、機能が明確で重複がなく、効率的な情報取得を促すように設計します。 例（Few-shot prompting）: 複雑な挙動を期待する場合は、多様で代表的な「成功例」をプロンプトに含めることで、LLMに期待する動作を効率的に教えることができます。また、長期的なタスクでは、コンテキストを動的に管理する技術も不可欠です。
Just in Time Retrieval: 必要な情報を事前に全て読み込むのではなく、エージェントがツールの使用を通じて、必要な時に必要な情報だけを動的に取得するアプローチです。これは、人間がファイルシステムやブックマークを使って情報を整理し、必要な時に参照するのと同じような考え方です。 コンパクション（Compaction）: 会話履歴が長くなりすぎた場合に、その内容を要約し、重要な情報だけを新しいコンテキストとして引き継ぐことで、過去の情報を忘れずに新しい会話を継続できます。 構造化されたメモ取り（Structured Note-taking）: エージェント自身がコンテキストウィンドウの外にメモ（例：TODOリストや進行状況）を保存し、後で参照することで、コンテキストの限界を超えた長期的な記憶を持たせることが可能になります。 サブエージェントアーキテクチャ: 複雑なタスクを、専門分野を持つ複数の「サブエージェント」に分割して実行させ、各サブエージェントは詳細な作業を行い、その要約だけをメインのエージェントに報告します。これにより、全体として効率的にタスクを進めることができます。コンテキストエンジニアリングの目的は、LLMの限られた注意力という予算の中で、「望ましい結果を出す可能性を最大化する、高信号な（重要な）トークンの最小セット」を見つけ出すことです。モデルの能力が向上しても、コンテキストを貴重なリソースとして賢く扱うという原則は、信頼性の高いAIエージェントを構築する上で常に中心的な考え方となるでしょう。
引用元: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
“虚空を見つめる猫”になって事故物件を探索するホラーゲーム『The Way hOme』発表。怪異を祓うまで、執拗に見つめ続けようJoyful Calamityから、新作ホラーゲーム『The Way hOme』が発表されました。プレイヤーは「怪異が見える猫」として、日本の事故物件を探索し、怪異を除霊しながら飼い主の霊魂を探します。特徴は、猫ならではの「見つめる」「引っ掻く」「嗅ぐ」といったアクションを駆使して進めるユニークなゲームプレイです。Unreal Engine 5で描かれるフォトリアルなグラフィックにも注目。2025年10月30日にPCとコンソール向けに発売予定です。
引用元: https://news.denfaminicogamer.jp/news/250930a
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
youtube版(スライド付き)関連リンク あえて二度手間することで取り戻す、AI時代のコーディングの楽しさ
最近、AIエージェントの進化により、開発スピードが驚くほど向上し、短時間でプロトタイプが作れるようになりました。しかし、この便利さの裏で、筆者は「コーディング本来の楽しさが半減している」というモヤモヤを感じています。
このモヤモヤの正体は、従来の開発にあった「学習」「理解」「試行錯誤」という重要なプロセスが、AI任せの開発ではごっそり抜け落ちてしまうことにありました。AIが代わりにコードを書いてくれるため、自分で調べたり、エラーと格闘したりする経験が減り、結果として以下の問題が生じます。
ノウハウが溜まらない: コードが動いても、なぜ動くのかの深い理解がないため、次に同じ問題に直面してもまたゼロから考えることになります。 トラブルシューティングができない: 自分で試行錯誤していないため、バグが発生してもどこを直せばいいのか見当がつきにくくなります。 メンテナンスが辛い: AIが生成したコードは、まるで他人が書いたかのように感じられ、改修や修正が困難になります。そこで筆者が提案するのが「二度手間開発」です。これは、まずAIを使って最短で動くものを作り、次にそのAIが作ったコードを参考にせず、自分でゼロから同じものを作り直すという方法です。AIのコードは「チートシート」や「模範解答」のように活用し、わからない時だけ参照します。
実際に「二度手間開発」を試したところ、Chrome拡張機能の開発を通じて、WXTの設定の深い理解や、AIコード内の不要な部分の発見、さらにユーザー体験を向上させるアイデアなど、多くの具体的な学びと気づきがあったそうです。自分で手を動かすことで、コードがなぜ動くのか、どうすればもっと良くなるのかを深く考える機会が得られます。
「二度手間開発」を始めるコツは、AIのコードをあえて読まず、新しいプロジェクトで一から作り直すことです。そして、本当に困った時だけAIのコードを見てヒントを得ます。
AIは非常に強力なツールですが、効率化だけを追求すると、エンジニアとしての成長やコーディングの楽しさを失う可能性があります。あえて遠回りする「二度手間開発」を通して、AIを「学びのツール」として活用し、コーディング本来の喜びを取り戻すことができるでしょう。
引用元: https://www.m3tech.blog/entry/2025/09/29/110000
AIスパコン「さくらONE」のLLM学習ベンチマークによる性能評価 / SAKURAONE LLM Training Benchmarkingさくらインターネットが開発したAIスパコン「さくらONE」を用いて、大規模言語モデル（LLM）の学習性能を評価した発表です。新人エンジニアの皆さんも、最先端のAI開発を支えるインフラ技術の現状と課題に触れてみましょう。
1. LLM学習におけるインフラの重要性ChatGPTのような巨大なLLMの開発には、大量の計算を並行処理する高性能インフラが必須です。深層学習は、Webアプリとは異なり、大量のデータを一括処理する「バッチ型ワークロード」です。学習を高速化する「分散学習」には、主に以下の手法があります。
データ並列: モデルを複製し、各GPUに異なるデータを処理させます。 モデル並列: 巨大なモデルを分割し、複数のGPUで分担して処理します。モデルの大規模化に伴い、GPUメモリ容量やGPU間のデータ通信速度がボトルネックになりやすいため、RDMAのような高速ネットワーク技術が学習効率を大きく左右します。2. 国産AIスパコン「さくらONE」の特長「さくらONE」は、さくらインターネットがLLM開発向けに構築したマネージドHPCクラスタです。
高性能GPU計算ノード、超高速ネットワーク、スケーラブルなストレージを統合。 2025年のISC「TOP500」で世界49位の実績。特に、オープンなネットワーク技術（SONiC OS、800GbE Ethernet）を採用している点が特徴です。3. LLM学習ベンチマーク評価と結果さくらONEのLLM学習性能を客観的に評価するため、業界標準の「MLPerf Training」ベンチマークを実施しました。これは、GPT-3モデルの事前学習を対象に、目標精度達成までの実時間を計測するものです。結果として、さくらONEは業界標準の範囲内で高い演算効率を達成しました。特にGPU間通信を行うインターコネクトネットワークの高速性が確認されています。しかし、一部の他社システムと比較するとわずかな性能差があり、Ethernet (RoCEv2) とInfiniBandの技術的差異や、チューニングの改善余地が考察されています。ベンチマーク実施では、分散学習の概念や複雑なソフトウェアスタック（Slurm、NeMoなど）の習得、最適な設定を見つけるための試行錯誤が大変だったとのことです。
4. SRE視点からの学びと今後の展望今回の取り組みは、SRE（サイト信頼性エンジニア）がAIスパコンの性能評価に挑んだ貴重な経験談です。
クラウドとHPCの思想: クラウドが柔軟なスケールアウトを重視する一方、HPCは限られたリソースを最大限に活用することを目指します。 フレームワークの奥深さ: 分散学習フレームワークの設定は、深い理論に裏打ちされており、体系的な理解が求められます。 オブザーバビリティの重要性: 効率的な性能改善には、システムやアプリケーションの動作状況を詳細に可視化する「オブザーバビリティ」が不可欠であり、今後の強化が課題です。さくらONEの性能評価は、国内のAIインフラ技術の発展に寄与し、LLM開発をさらに加速させる重要な取り組みと言えるでしょう。
引用元: https://speakerdeck.com/yuukit/sakuraone-llm-training-benchmarking
Smart Multi-Node Scheduling for Fast and Efficient LLM Inference with NVIDIA Run:ai and NVIDIA Dynamo皆さん、こんにちは！AI技術の進化が目覚ましい中、特にLLM（大規模言語モデル）はどんどん複雑になり、その運用には新しい課題が生まれています。例えば、モデルが巨大すぎて1つのGPUでは動かせなかったり、大量の処理を素早く低遅延でこなす必要があったり、多くの部品（コンポーネント）が連携して動くインフラの調整が大変だったりします。この記事では、NVIDIAが提供する「Run:ai v2.23」と「Dynamo」という2つの技術が、これらの課題をどう解決してくれるのかを、新人エンジニアの方にも分かりやすく解説します。
まず、「NVIDIA Dynamo」は、LLMの推論を高速かつ効率的に行うために作られたフレームワークです。具体的には、
モデルの処理を「前処理（prefill）」と「生成（decode）」に分け、GPUの性能を最大限引き出す 要求の量に応じてGPUの割り当てを柔軟に変える LLMの特性に合わせてリクエストを効率的に振り分ける データ転送を速くする技術（NIXL）を使う KVキャッシュという重要なデータを効率的に管理するといった機能を持っています。これにより、巨大なLLMでも分散されたGPUクラスター上でスムーズに動かせるようになります。しかし、Dynamoがどんなに優れていても、たくさんの部品が絡み合うLLMの推論を複数のコンピューター（ノード）で動かすには、その部品たちをどこに、いつ、どのように配置・起動するかがとても重要になります。ここが「スケジューリング」という部分で、もしこの調整がうまくいかないと、GPUが無駄に待機してしまったり、部品間の通信に時間がかかって全体の性能が落ちてしまったりします。
そこで活躍するのが「NVIDIA Run:ai v2.23」です。Run:aiは、特に2つの強力な機能でこのスケジューリングの課題を解決します。
ギャングスケジューリング（一括起動）: Dynamoの各部品は密接に連携しているため、どれか一つでも欠けると処理が進みません。ギャングスケジューリングは、これらの関連する部品群を「一つのまとまり」として扱い、必要なリソースが全て揃ってから一斉に起動します。これにより、中途半端な状態でリソースを占有するのを防ぎ、GPUの利用効率を大幅に向上させます。 トポロジー認識型配置（最適な場所に配置）: クラスター内のコンピューターの物理的な配置（ネットワークの近さなど）をRun:aiに教えてあげることで、スケジューラは、連携が密な部品同士を物理的に近い場所に配置するようにします。これにより、部品間のデータ通信にかかる時間を最小限に抑え、大規模なLLMでも低遅延で高性能な推論を実現します。まとめると、NVIDIA DynamoがLLM推論の内部効率を高め、NVIDIA Run:ai v2.23がその効率を最大限に引き出すための最適な配置と起動を自動で行ってくれる、というわけです。この2つの技術を組み合わせることで、LLMの運用におけるボトルネックを解消し、より高速で効率的、そして安定したAIサービスを提供できるようになります。AIエンジニアとして、大規模なLLMを扱う際には、このようなインフラ側の工夫が非常に重要になることをぜひ覚えておいてください。
引用元: https://developer.nvidia.com/blog/smart-multi-node-scheduling-for-fast-and-efficient-llm-inference-with-nvidia-runai-and-nvidia-dynamo/
いつも視力測定カンストするくらい目が良いが、学生時代はもっと良くて、肉眼で土星の輪っかを観測する事が出来ていたので天文部で『土星探す係』をやらされていたにじさんじのグウェル・オス・ガールさんが、学生時代に驚くほど視力が良かったというエピソードが話題です。なんと、肉眼で土星の輪や金星の満ち欠けまで見分けられたため、天文部では「土星探す係」を担当していたそうです。現在の視力も非常に良いとのこと。この超人的な視力に対し、SNSでは「まるでエルフのようだ」「漫画のキャラクターみたい」と驚きと羨望の声が上がっています。こんなすごい目を持っていたら、どんな景色が見えるのか想像が膨らみますね！
引用元: https://togetter.com/li/2608904
お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）
-
関連リンク AI エージェント用の Chrome DevTools（MCP） Blog Chrome for Developers
Chromeの開発チームは、AIエージェント向けの新しいツール「Model Context Protocol（MCP）サーバー」の公開プレビューを開始しました。これは、AIを活用した開発を大きく変える可能性を秘めています。
これまでAIコーディングアシスタントは、コードを生成できても、それが実際にブラウザでどう動くのかを直接確認するのが苦手でした。例えるなら、目隠しをしてプログラミングしているようなもので、問題の発見や修正が難しかったのです。
この課題を解決するため、Chrome DevTools MCPサーバーが登場しました。MCPとは、大規模言語モデル（LLM）のようなAIを外部のツールやデータに接続するためのオープンな標準プロトコルです。このサーバーは、AIエージェントにChrome DevToolsの強力なデバッグ機能やパフォーマンス分析機能を使えるようにします。これにより、AIがウェブページを直接チェックし、まるで人間のように問題を見つけて修正できるようになります。
AIエージェントがMCPサーバーを使うことで、以下のような様々なことが可能になります。
コード変更のリアルタイム検証: AIが生成したコードが、ブラウザで期待通りに動作するかを自動で確認できます。 ネットワークやコンソールエラーの診断: ウェブページで画像が読み込まれない、フォームの送信に失敗するといった問題を、AIがネットワークリクエストやコンソールログを分析して原因を特定します。 ユーザー行動のシミュレーション: AIが、フォーム入力やボタンクリックなどのユーザーの操作をシミュレートし、複雑なユーザーフローにおけるバグを発見します。 スタイリングやレイアウト問題のデバッグ: AIがライブのウェブページを検査し、CSSの崩れやレイアウトの乱れといった視覚的な問題を特定し、具体的な修正案を提案します。 パフォーマンス監査の自動化: ウェブサイトの読み込み速度が遅い場合、AIが自動でパフォーマンスを計測・分析し、改善のための具体的なアドバイスを提供します。この新しいMCPサーバーは、簡単な設定を加えるだけで、すぐに試すことができます。AIエージェント開発者は、GitHubのドキュメントで詳細な使い方を確認できます。
この機能はまだプレビュー版で、開発チームはAIを活用した次世代の開発ツールをより良くしていくために、ユーザーからのフィードバックを積極的に募集しています。ウェブ開発におけるAIの可能性を広げる、非常にエキサイティングな一歩と言えるでしょう。
引用元: https://developer.chrome.com/blog/chrome-devtools-mcp?hl=ja
Multi Agentを介した知識の活用の検討 - Preferred Networks Research & DevelopmentPreferred Networks（PFN）が、複数のAIを協力させて知識を最大限に活用する「Multi Agent（マルチエージェント）」という新しい手法の研究成果を発表しました。新人エンジニアの皆さんも、ぜひ知っておきたいAIの最新の活用事例です。
この研究では、AI同士が議論しながら最適な答えを見つける「LLM Debate（エルエルエムディベート）」というMulti Agentの手法を使いました。具体的には、PFNが独自に開発した医療分野に特化したAI「Preferred-MedLLM-Qwen-72B」と、高性能な汎用AIである「GPT-4o」を組み合わせ、医師国家試験の問題を解かせました。
AIを単体で使う場合、それぞれが持つ知識には得意なことと苦手なことがあります。そこで、両方のAIを協調させることで、お互いの得意な知識を補い合い、より正確な答えを導き出すことを目指しました。実験の結果、Preferred-MedLLM-Qwen-72BとGPT-4oを連携させた場合、単体で問題を解くよりも平均で約15点も正解率が向上し、医師国家試験で90%を超える高い正解率を達成しました。
この研究から、特に重要な点が2つ見つかりました。
専門知識を持つAIの重要性: ドメイン特化の学習をしていない一般的なAIとGPT-4oを組み合わせた場合は、正解率の向上がほとんど見られませんでした。この結果は、特定の分野の深い知識を持つAI（Preferred-MedLLM-Qwen-72Bのようなモデル）が、他のAIと協力して複雑な問題を解決する上で、非常に重要であることを示しています。専門知識があるからこそ、質の高い議論ができると言えるでしょう。 AIの汎化性能: Preferred-MedLLM-Qwen-72Bは、単に問題を解くだけでなく、他のAIが出した答えを評価したり、さらに良い答えを考えたりする「回答評価」のような、より複雑なタスクでも高い能力を発揮しました。これは、特定のタスクだけでなく、様々な指示や状況に対応できる「汎化性能」が高いことを示しており、このAIが幅広い用途で活用できる可能性を秘めていることを意味します。この研究は、強力な汎用AIと、特定の専門分野に特化したAIをうまく組み合わせることで、AIの推論能力をさらに引き出せることを示しています。PFNは、この知見を今後のAI研究開発や、実際の社会課題解決のためのソリューション開発に活かしていく方針です。異なるAIの「得意」を組み合わせて、これまでにない価値を生み出すこの研究は、私たちエンジニアがAIの未来を考える上で、非常に刺激的で希望に満ちた内容だと言えるでしょう。
引用元: https://tech.preferred.jp/ja/blog/medllm-multi-agent/
決定論的システムと非決定論的AI Agentの接合点：OSSフレームワークEmbabelが拓く新しいソフトウェア開発の可能性ログラスが発表した「Loglass AI Agents」構想は、従来のSaaSが扱う「決定論的な」タスク（常に同じ結果が期待される）に加え、「非決定論的な」タスク（毎回結果が変動しうる）もAI Agentで実現し、より良い意思決定を支援することを目指します。
しかし、AIエージェントの活用には大きな課題があります。AIエージェントは高度な能力を持つ一方で、同じ指示を与えても結果が毎回異なる「非決定論的な」振る舞いをすることがあります。これは、会計システムのように「同じ入力には常に同じ出力」が求められる従来の業務アプリケーションの信頼性や一貫性とは相性が悪く、ビジネスでAIエージェントを安心して使う上での大きな障壁です。
この課題を解決するため、Springフレームワーク開発者のRod Johnson氏がOSSのAIエージェントフレームワーク「Embabel」を開発しました。EmbabelはKotlin製で、「生成AIを安全かつ信頼性の高いものにし、ビジネス価値を最大限に引き出す」ことを目的としています。特に、決定論的な要素と非決定論的な要素が混ざった業務の解決に貢献します。
Embabelの主な特徴は二つです。
GOAPによる決定論的な計画ステップ: 多くのAIエージェントが大規模言語モデル（LLM）に全てを任せるのに対し、Embabelはタスク実行前に「GOAP（Goal Oriented Action Planning）」というLLM非依存のアルゴリズムで行動計画を立てます。これにより、エージェントの動きが予測可能になり、信頼性が求められるタスク（データ検索など）はプログラムで確実に処理し、LLMは創造的なタスク（返答生成など）に集中できます。 ドメインモデルと型安全性（DICE）: AIエージェント開発では、LLMとのやり取りが型のないデータになりがちで堅牢性が低下する問題がありました。Embabelは厳密な型を持つ「ドメインモデル」の利用を推奨します。これを「DICE（Domain-Integrated Context Engineering）」と呼び、既存のビジネス知識をAIの文脈に統合。型安全なデータでLLMが既存システムと連携できるようになり、堅牢な開発が可能になります。Embabelは、これらの特徴を通じて、企業レベルで信頼性のあるAIエージェントの実現を目指します。AIエージェント開発はまだ黎明期ですが、Embabelのようなフレームワークは、従来のシステムとAIの創造性を融合させ、全く新しい「AIネイティブなプロダクト」を創造する鍵となるでしょう。
引用元: https://zenn.dev/loglass/articles/e6525e7e8b7a69
お便り投稿フォームVOICEVOX:春日部つむぎ
- Show more
