youtube版(スライド付き) 関連リンク Agent Engineering: A New Discipline AIエージェントを開発している皆さん、自分のPCでは動いていたのに、いざ本番環境にデプロイすると予期せぬ挙動をして苦労した経験はありませんか？従来のソフトウェア開発では、入力と出力がある程度予測できましたが、AIエージェントはユーザーがどんな入力をしてくるか分からず、挙動も広範囲にわたるため、開発が非常に難しいのが現状です。そこで、LangChainのチームは、AIエージェントを本番環境で信頼性高く運用するための新しい開発手法として、「エージェントエンジニアリング」という専門分野を提唱しています。これは、予測不可能な大規模言語モデル（LLM）ベースのシステムを、信頼できるプロダクトへと継続的に改善していくための反復的なプロセスです。そのサイクルは、「構築（Build）」「テスト（Test）」「リリース（Ship）」「観察（Observe）」「改善（Refine）」「繰り返し（Repeat）」が基本となります。ここで大切なのは、リリースがゴールではなく、新たな知見を得てエージェントを改善するための出発点である、という考え方です。エージェントエンジニアリングを実践するには、主に3つのスキルセットが連携する必要があります。プロダクト思考: エージェントが「何を解決すべきか」を定義し、ユーザーの課題を深く理解します。具体的なプロンプト作成や、エージェントが期待通りに動くかを評価する指標作りも含まれます。エンジニアリング: エージェントが利用するツール（外部サービス連携など）を開発したり、ユーザーインターフェース（UI/UX）を構築したり、エージェントの実行を安定させるための基盤（エラー処理、メモリ管理など）を作ります。データサイエンス: エージェントの性能や信頼性を測定するシステム（A/Bテスト、モニタリングなど）を構築し、実際の利用データから改善点を見つけ出します。なぜ今、この分野が必要なのでしょうか？ LLMは今や複雑な多段階のタスクをこなせるほど強力になりましたが、その強力さゆえに予測不可能な挙動も増えました。従来の開発では「すべてテストしてからリリース」でしたが、AIエージェントの場合、ユーザーの自然言語入力は「すべてがエッジケース」になり得ます。また、モデル内部のロジックが多いため、従来のデバッグ方法では対応しきれません。「動いている」だけでは不十分で、「意図通りに、適切に動いているか」を常に監視・評価する必要があります。エージェントエンジニアリングでは、「完璧にしてからリリースする」のではなく、「リリースして現実世界での挙動から学ぶ」という考え方が重要です。まずエージェントの土台を作り、想定シナリオでテストし、すぐにリリースして実際のユーザー入力を観察します。そこから得られた情報をもとに、プロンプトやツール定義を改善し、このサイクルを素早く繰り返すことで、信頼性の高いエージェントシステムを構築できるのです。 AIエージェントは、これまで人間が行っていた複雑な作業をこなす大きな可能性を秘めています。この新しい開発手法をチームに取り入れることで、LLMの真の力を引き出し、信頼できるプロダクトを生み出すことができるでしょう。引用元: https://blog.langchain.com/agent-engineering-a-new-discipline/ GitHub Copilot サブエージェントによるオーケストレーターパターンの実践この記事は、GitHub CopilotのrunSubagentという機能を使って、ソフトウェア開発のワークフロー全体を自動化する「オーケストレーターパターン」について、新人エンジニアにも分かりやすく解説しています。 GitHub CopilotのrunSubagentとは？これは、AIエージェントが別のAIエージェントに仕事を依頼できる便利な機能です。まるで、会社で上司が部下に具体的な業務を指示するようなイメージです。オーケストレーターパターンとは？この記事で紹介されているオーケストレーター（指揮者）エージェントは、ソフトウェア開発の最初から最後まで、すべてを自動で進めるシステムです。具体的には、ユーザーが「こんな機能が欲しい」と要望を出すと、以下の開発プロセスを自動で実行します。 Issue作成：要望を基に、開発課題（Issue）を作成します。計画立案：課題解決のための実装計画を立てます。実装：計画に従って、テストを書きながらコードを実装します。レビュー：書かれたコードをレビューし、改善点を指摘します。 PR作成：最終的に、実装とレビューが完了したコードをGitHubに提出するためのプルリクエスト（PR）を作成します。この一連の作業を、オーケストレーターがそれぞれの専門家である「サブエージェント」に任せることで、開発プロセスをスムーズに進めます。このシステムの設計で大切なこと責任分離の明確化：まるで会社の部署のように、各エージェントに「Issueを作成する」「計画を立てる」といった明確な役割を与えます。これにより、エージェントが自分の担当以外のことを勝手に判断するのを防ぎ、システム全体がきちんと動くようになります。モジュール化のメリット：各エージェントの定義（どのような仕事をするか）を別々のファイルに分けて管理します。こうすることで、特定のエージェントだけを改善したり、人間が直接使ったりすることが簡単になります。コスト効率：通常、開発の各フェーズでCopilotに何度も指示を出す必要がありますが、オーケストレーターを使えば、ユーザーからの指示は最初の1回だけで済みます。これにより、Copilotのリクエスト回数制限があるプランでも、リクエスト数を節約できます。実際に作ってみてわかった注意点エージェントの忠実さ：オーケストレーターがサブエージェントに仕事を頼む際、サブエージェントの指示内容を勝手に「改善」しようとすることがありました。しかし、システム全体の一貫性を保つためには、エージェントは与えられた定義に忠実に動くことが重要です。責任範囲の教育：オーケストレーターがユーザーの曖昧な要望を自分で解釈しようとすることがありました。しかし、その役割はIssueエージェントにあるため、「これはあなたの仕事ではない」と明確に指示することで、適切に役割分担ができます。今後の展望現時点では、複数のサブエージェントを同時に動かす（並列実行）ことはできませんが、このオーケストレーターパターンは、将来のAIを活用した開発をよりスマートにするための強力なアプローチです。新人エンジニアの皆さんも、このようなAIエージェントの活用方法を知ることで、これからの開発にどうAIが関わってくるか、イメージしやすくなるでしょう。引用元: https://zenn.dev/openjny/articles/e11450f61d067f Apriel-1.6-15b-Thinker: Cost-efficient Frontier Multimodal Performance Hugging FaceとServiceNow AIが、新しいマルチモーダルAIモデル「Apriel-1.6-15b-Thinker」を発表しました。このモデルは150億パラメータという、大規模モデルと比べると比較的小さな規模でありながら、非常に高い性能と優れたコスト効率を両立しているのが大きな特徴です。 Apriel-1.6は、前バージョン（Apriel-1.5）を基盤に、テキストと画像の理解・推論能力を大幅に強化しました。人工知能の総合評価指標である「Artificial Analysis Index」では57点を獲得し、Gemini 2.5 FlashやClaude Haiku 4.5といった主要な大規模モデルを上回る、あるいは匹敵する最新最高の技術水準（SOTA）の性能を発揮しています。特に注目すべきは、推論時に使用するトークン（単語や文字の単位）の量が、前バージョンと比較して30%以上も削減されている点です。これは、より少ない計算リソースで、より高速かつ効率的に推論ができることを意味します。モデルの学習には、NVIDIAの最新チップ「GB200 Grace Blackwell Superchips」が活用され、約1万GPU時間という比較的少ない計算資源で効率的に行われました。学習プロセスでは、まず多様なデータで初期学習を行い、その後、以下の二段階でさらに性能を高めています。教師ありファインチューニング（SFT）: モデルが「なぜその答えになるのか」という思考過程（推論トレース）をステップバイステップで学習させ、答えだけでなくその理由も明確にする能力を高めました。強化学習（RL）: 正しい回答には報酬を与え、冗長な説明や不正確な形式には罰則を与えることで、より効率的で直接的な回答を促しています。これらの工夫により、テキスト理解に加え、画像に関する数学的推論、視覚的質問応答（VQA）、論理推論など、画像関連のタスクでも大きく性能が向上しました。 Apriel-1.6の最大の強みは、「コスト効率の良いフロンティア性能」です。これは、少ないパラメータ数（モデルの規模を示す指標）で、大規模モデルに匹敵する「知能スコア」を実現していることを意味します。つまり、運用にかかる計算リソースや費用を大幅に抑えながら、最先端の推論能力を発揮できるため、特に企業でのAIシステム導入において、非常に魅力的な選択肢となります。開発チームは、限られたリソースでも「適切なデータ、設計、堅実な手法」があれば、最先端のモデルを構築できることを証明しました。一部の複雑な画像やOCR（文字認識）の精度にはまだ課題があるものの、彼らは高性能と推論トークンの効率性を優先して開発を進めています。この取り組みは、新人エンジニアの皆さんにとって、限られた環境でもイノベーションを生み出せる可能性を示唆していると言えるでしょう。引用元: https://huggingface.co/blog/ServiceNow-AI/apriel-1p6-15b-thinker 【検証】夜泣き対応で絶望したので、娘の泣き声を最新LLMに「翻訳」させてみた最新LLMを使い、プロダクトマネージャーが赤ちゃんの泣き声を分析し、夜泣き対応の課題解決を検証しました。単発の泣き声から理由を特定するのは困難でしたが、複数の泣き声を比較する「相対評価」では、LLMは泣き声の特徴を正確に捉えました。ChatGPTは慎重な姿勢、Geminiは断定的な傾向、Claudeは詳細な音響分析が特徴です。今後は継続的な分析や、授乳などの文脈情報を加えることで、実用レベルへの精度向上が期待されています。AIによる励ましの言葉も、育児のUXとして価値があると考えられています。引用元: https://qiita.com/Kuroyanagi96/items/cb89339b3dda509c7ff5 お便り投稿フォーム（株式会社ずんだもんは架空の登場組織です）

Ask this episode

“What did the council decide on item 42?” — answered with the speaker and the moment.

Transcript

Related