はじめに NTT西日本の服部です。本記事ではMicrosoft Forms、Microsoft Lists、Power Automateを使って、ブログ記事のレビュー効率化を実現したのでご紹介します。 以下6回のシリーズで第1回となる今回は概要編としてワークフローの検討内容や構築したリソースの概要についてご紹介します。 本記事は2025年9月時点の情報に基づきます。 ①~概要編~ (本記事) ②~Microsoft Lists/Microsoft Forms~ ③~Power AutomateによるMicrosoft Listsへの自動登録編~ ④~Power Automateによるレビューフロー前編~ ⑤~Power Automateによるレビューフロー中編~ ⑥~Power Automateによるレビューフロー後編~ 対象読者 本記事が想定する対象読者は以下の通りです。 自動化に興味がある人 繰り返しの定常的な作業に困っている人 Microsoft Forms/Microsoft Lists/Power Automateを使ってみたい人 背景 NTT WEST Engineers' Blog に向けて、ブログ記事のレビュープロセスを効率化したいという要望を受けて執筆者が検討・構築しました。 SaaSの新規サービスを導入する予算はありませんでしたが、幸い全社的にMicrosoft Forms、Microsoft Lists、Power Automateが利用できる環境だったため、これらを用いてブログ記事レビューのワークフローを構築しました。 使用するツールの紹介 レビューフロー構築にあたり使用したツールを簡単にご紹介します。 Microsoft Forms Microsoft 提供するアンケート、クイズ、投票フォームを簡単に作成・共有できるWebツールです。 今回は投稿者がレビュー依頼を申し込むためのフォームとして利用します。 Microsoft Forms とは - Microsoft サポート Microsoft Lists Microsoft が提供する情報追跡アプリで、チームで情報を整理、共同作業、共有するのに役立つツールです。 今回はSharepoint上に構築し記事の提出状況やレビュー進捗をトラッキングするために使用します。 Microsoft 365 のリストとは何ですか? - Microsoft サポート Power Automate Microsoftが提供するクラウドベースのRPAツールで、プログラミング知識がなくても、日常の繰り返し作業や部門間の連携などを自動化する「ワークフロー（フロー）」をノーコードで作成できます。 Microsoft Forms の回答を検知してMicrosoft Listsに自動で登録したり、投稿者やレビュアーへ通知したりといった処理を自動化するために使用します。 Microsoft Power Automate – Process Automation プラットフォーム | Microsoft レビューフローの全体像 はじめにレビューフロー構築のためにどういった処理が必要か整理しました。 大まかな流れは以下の通りです。 ①. 投稿者がMicrosoft Formsでレビュー依頼をあげる。 ②. Formsの回答内容をListsに自動登録する。 ③. 運営担当者にレビュアーのアサインを依頼する。 ④. レビュアーにレビュー依頼を通知し、レビューを対応する。 ⑤. 必要に応じて記事の修正を依頼する。 ⑥. レビューが完了したら記事を公開し、投稿者に通知する。 実際に対応するときの考慮事項を踏まえて整理した結果、レビューフローの全体像は以下のようになりました。 ※あくまでイメージです。実際に構築したリソースの処理の流れとは一部異なる部分があります。 破線の矢印：PowerAutomateで自動的に処理される内容 実線の矢印：ユーザーによる操作等を表す内容 構築したリソース 整理したレビューフローを実現するために以下のステップに分けてリソースを構築しました。 詳細については次回以降にご紹介します。 1.Microsoft Formsでレビュー依頼フォームに回答する。 投稿者がレビューを依頼するための申し込みフォームを構築しました。 詳細は 第2回 で紹介します。 2.Microsoft Listsで進捗管理リストに登録する。 レビューの進捗を管理するために以下のようなMicrosoft Listsを構築しました。 Microsoft Listsの詳細は 第2回 で紹介します。 また、Microsoft Formsの回答送信を検知してMicrosoft Listsに自動登録するためのPower Automateのクラウドフローを構築しました。 Microsoft Formsの回答内容をMicrosoft Listsに自動登録するPower Automateの詳細は第3回で紹介します。 3.レビュアーのアサインを依頼する。 新規のレビュー依頼がきたときには運営の担当者にレビュアーをアサインするように依頼するためのPower Automateのクラウドフローを構築しました。 こちらの詳細は第4回で紹介します。 4.レビュー対応をする。 レビュアーとして設定された担当者宛にレビュー依頼をあげて応答内容を処理するためのPower Automateのクラウドフローを構築しました。 このフローは修正された記事に対する再レビュー依頼をあげる際にも呼び出されます。 こちらの詳細は第5回で紹介します。 5.必要に応じて修正依頼を出す。 レビューの結果、投稿者に修正を依頼するためのPower Automateのクラウドフローを構築しました。 こちらの詳細は第6回で紹介します。 6.記事公開について投稿者に通知する。 レビューが完了し、記事が公開されたことを投稿者に通知するためのPower Automateのクラウドフローを構築しました。 こちらの詳細は第6回で紹介します。 まとめ 今回は本ブログ開設にむけて構築した投稿記事レビューのワークフローとリソースの概要をご紹介しました。 次回以降で各リソースの詳細をご紹介していきます。 執筆者 服部 真智(NTT西日本 ビジネス営業本部所属) 普段はAWS案件の提案、設計、構築等の支援を行っています。 自業務の効率化のためにPython,Power Automate,生成AI等を使って日々試行錯誤しています。 2025 Japan AWS Top Engineers (Services) 商標 Microsoft (Microsoft Entra 、 Microsoft Teams 、 Power Automate 、 Microsoft Lists 、 Microsoft Forms)及び関連する名称並びにそれぞれのロゴは、米国 Microsoft Corporation の米国およびその他の国における商標または登録商標です。

はじめに NTTスマートコネクトの山下です。昨今、生成AIを活用したソフトウェア開発が注目されています。特にコーディングにおいて日夜さまざまなコーディング支援ツールが登場し、その利用法が模索されています。本記事では生成AIを用いたAIコーディングの概要からコーディングのスタイルについて紹介いたします。 ※この記事は2025年8月現在の情報に基づきます 対象読者 本記事で想定する対象読者は以下の通りです。 生成AIを用いたソフトウェア開発に興味がある人 AIコーディングツールの導入を検討している人 AIコーディングを学ぼうとしている人 背景 2022年末のChatGPT登場以降、生成AIを活用したコーディング支援ツールが発展し、ソフトウェア開発に大きな影響をもたらしています。しかし、これらのツールを効果的に活用するためには、AIコーディングに合わせたやり方を身につける必要があります。筆者自身、2024年12月からCursor、2025年6月からClaude Codeを利用しAIコーディングには特有の進め方があることを実感しました。本記事では、その経験から得られた知見を共有し、AIコーディングツールをより効果的に活用するためのアプローチを紹介します。 AIコーディングとは 従来、ソフトウェア開発のコーディングは人が行っていました。要件定義、設計を経てプログラミング言語とエディタと呼ばれるツールを用いてシステムの挙動となるロジックを記述します。またコーディングも負荷を軽減するために、静的解析や補完によって入力を支援するツールが用いられてきましたが、あくまで人が記述することを前提とされています。 ChatGPT登場以降、急速にAIにコーディングさせようとする試みが発展しています。 最初は生成AIをプロンプトを送り、応答結果のソースコードを用いる方法が試されます。 しかし、プロンプトだけでは得られる情報が限られるため、外部の情報にアクセスする技術（RAG）やツール呼び出し(Function calling)などのプロンプト以外から情報を得る技術が注目され、これらの技術はコーディングの場に限らず用いられるようになりました。 またコーディングでは要件や設計などの情報からタスクを計画し、実行する能力が必要となります。タスクの計画と実行をAIが代行する、AIエージェントという仕組みが導入され始めました。このAIエージェントの技術によってコーディング内容を事細かに指示することなく自律的なコーディングが可能となりました。本記事のAIコーディングはAIエージェントを用いたコーディングを前提とします。 AIコーディングは一般的に生成AIと連携してコーディングするツールを利用します。 ここでAIコーディングツールの一例としてCline、Cursor、Claude Codeという3種類のツールを紹介します。 ClineはVisual Studio Codeの拡張機能として動作するオープンソースのコーディングエージェントです。 複数のAIプロバイダー（Claude、OpenAI、Gemini等）に対応しています。AIエージェントとして後述のツールよりも先行してリリースされています。またClineからRoo Codeなど派生ツールが誕生しています。 CursorはAnysphere社が提供するVisual Studio CodeをベースとしたGUIコードエディターです。当初はAIエージェントの機能はなく、入力指示を送りAIで修正する形態でしたが2024年11月にAgentモードがリリースされました。そして2025年8月にCLI版のCursor CLIがリリースされました。 Claude CodeはAnthropic社が提供するCLIで動作するエージェント型コーディングツールとして2025年5月にリリースされました。Anthropic社はClaudeという生成AIを開発しており、1日あたり5時間以内であれば制限なくClaude CodeからClaudeを利用できます。（2025年8月28日から週単位に制限が追加予定） ツール名 特徴 開発元 主な提供形態 Cline Visual Studio Codeの拡張機能として動作するオープンソースのコーディングエージェント（Roo Code等の派生含む） コミュニティ オープンソース Cursor Visual Studio CodeをベースとしたGUIコードエディター Anysphere社 無料 / 有料 Claude Code CLIで動作するエージェント型コーディングツール Anthropic社 有料（定額 / 従量） 上記以外にもAIコーディングのツールは多数提供されており、日々これらのツールが登場しアップデートされています。開発者体験やシステム連携などを考慮して選定する必要があります。 AIコーディングではこれらのツールを利用して生成AIに対して情報を提供し指示することでコーディングを進めていきます。 AIコーディングのスタイルについて 筆者は2024年12月からCursor、2025年6月からClaude Codeを主に利用しています。 初めてAIコーディングをした際は曖昧な指示でコーディングが進むことに感動しました。 しかし早々に、思ったようにコーディングが進まない状態になりました。 AIコーディングにはAIコーディングのアプローチの方法（スタイル）があり、そのスタイルについて知る必要があったのです。 AIコーディングのスタイルとして2つの概念を紹介したいと思います。それは、 「バイブコーディング（Vibe Coding）」と「エージェンティックコーディング（Agentic Coding）」です。 バイブコーディングはOpenAIの共同設立者でもあるアンドレイ・カーパシー氏によって提唱された用語で生成AIと対話をしながら創発的なコーディングを行います。エージェンティックコーディングは高レベルの目標からタスク計画、実行、検証、修正までをエージェントが自律的に行います。 AIエージェントを用いた場合、バイブコーディングでは抽象的な指示に対してもAIエージェントが解釈しコーディングを進めます。一方でエージェンティックコーディングでは、目標設定以降は人を介さずAIエージェントの機能をフル活用するやり方です。 筆者は、はじめてAIコーディングを始めた際にバイブコーディングによって曖昧な指示でさえも動くアプリケーションが生成されることに感動しました。手作業では何時間もかかるであろう実装がAIコーディングによってものの数分で出来上がるのです。 しかし、バイブコーディングを続けているとある問題が発生します。システムの規模がある程度を超えると、コーディングの精度が低下するように感じられます。具体的には、リクエストした機能が実装されない。指摘した修正がいつまでも直らないといったことが起こりました。1、2時間で8割できたものの、残り2割が半日たっても出来上がらないのです。 その原因は何でしょうか？それは、生成AIは一度に無限の情報を扱えるわけではなく、限られた量の情報しか扱えないことにあります。コーディングを進めるなかで扱う情報量が増えていくことで意図した修正が行われないことになります。AIコーディングツールは情報の圧縮や要約する技術を用いて、処理を継続しようとしますが、大きなシステムをすべて探索して的確に修正していくことは困難になります。 そこでエージェンティックコーディングのように戦略的に計画的にタスク設計し、情報を整理しながらコーディングを遂行する考え方を取り入れる必要があります。 バイブコーディング一辺倒ではなく、バイブコーディングやエージェンティックコーディングを適材適所で使い分ける必要があります。例えば、小規模なプロトタイピングではバイブコーディングで行い、システムの要件が明確になったら、エージェンティックコーディングで開発を進める、というように状況によってこれらを組み合わせることも考えられます。 AIコーディングの登場によってエンジニアのコーディング量は減少する可能性が高い一方、これらのスタイルを戦略的に使い分け、開発の見通しを立てることがより重要な仕事になります。 今後もAIコーディングをとりまく状況は間違いなく変化していきますが、AIに ”丸投げ” するのではなく、AIと協調し、ともに成長していく姿勢こそが、結果として良いプロダクトを生み出す近道になるのかもしれません。 まとめ AIコーディングの概要とAIコーディングツールの紹介を行いました。またAIコーディングのスタイルとしてバイブコーディングとエージェンティックコーディングについて説明しました。AIコーディングを進めるにあたって、状況に合わせたコーディングのスタイルを取り入れ、見通しを立てることがより重要になると筆者は考えます。 執筆者 山下　義陽（NTTスマートコネクト株式会社 ビジネスイノベーション部） NTTスマートコネクトの新規事業開発に従事し、医療機関向けのサービスや動画配信・ライブコマースの立ち上げや生成AIサービスの開発に携わっています。 参考資料・出典 本記事を執筆するにあたり、以下のサイトを参考にしました。 【論文】Vibe Coding vs. Agentic Coding: Fundamentals and Practical Implications of Agentic AI 【書籍】現場で活用するためのAIエージェント実践入門 【ポッドキャスト】fukabori.fm 131. AIコーディングの現在地 w/ twada 【ブログ】https://zenn.dev/mizchi/articles/all-in-on-cline 商標 「OpenAI」は、OpenAI, Inc.の商標もしくは登録商標です。 「ChatGPT」は、OpenAI OpCo, LLC の商標もしくは登録商標です。 「Claude」は、Anthropic PBC の商標もしくは登録商標です。 「Cursor」は、Anysphere, Inc. の商標もしくは登録商標です。 「Gemini」は、Google LLC の商標もしくは登録商標です。

はじめに NTTビジネスソリューションズの鶴田です。 最近話題の生成AIツール”Microsoft 365 Copilot”はとても便利ですが、何も考えずに導入してしまうと、機密情報の漏洩など、思いがけないセキュリティ事故につながってしまうリスクがあります。 本記事では、無防備にMicrosoft 365 Copilotを導入してしまうと、セキュリティリスクが増す理由と対処方法を解説させていただきます。 対象読者 本記事が想定する対象読者は以下の通りです。 Microsoft 365 Copilot におけるセキュリティ対策に興味がある方 Microsoft 365 Copilot の導入を検討されている方 Microsoft 365 Copilot を利用されている方 "AI × セキュリティ"全般に興味がある方 Microsoft 365 Copilot とは Teamsなどの Microsoft 365 アプリに組み込まれたAI機能のことです。 プロンプト（自然言語）で Microsoft 365 内のデータを操作（グループチャットの要約 等）することができます。 引用元: Microsoft Teams のチャットとチャネルで Copilot を使用する Microsoft 365 Copilot と Microsoft 365 データの関係 Microsoft 365 Copilot におけるセキュリティを考える上で、 最初に押さえておくべきポイントは、Microsoft 365 Copilot と Microsoft 365 データの関係 についてです。 Microsoft 365 Copilotは、Microsoft 365 内のいかなるデータにもアクセスできるのでしょうか？？ 答えは、 "いいえ" です。 大原則として、Microsoft 365 Copilotは、その Microsoft 365 Copilot を操作しているユーザが保持する ”Microsoft 365 データへのアクセス権”に基づいて動作 します。 たとえば、以下のプロンプト①は、ユーザAは自分自身の Exchange Online のメールデータにはアクセス可能なので機能する可能性があります。しかしながら、プロンプト②は、ユーザAはユーザBのExchange Online のメールデータにはアクセスできないので機能しません。 〇：プロンプト① ユーザA「昨日自分が受信したメールで未返信のものを教えて」 ×：プロンプト② ユーザA「ユーザB個人が受信したメールで重要そうなもの教えて」 Microsoft 365 Copilot におけるセキュリティリスクと対処方法 では、次に Microsoft 365 Copilot の利用において、どのようなセキュリティリスクがあるのか見ていきます たとえば、以下のようなシナリオが考えられます。 一般社員であるユーザAは、本来「経営に関わる重要な情報」へアクセスできません。しかし、ユーザAに対し、ファイルへの過剰なアクセス権が付与されている場合、Microsoft 365 Copilot は、「経営に関わる重要な情報」を回答してしまう可能性があります。 アクセス権のかけ方（フォルダ単位のアクセス制御） シンプルな対処方法は、フォルダ単位でアクセス制御をしておくことです。以下のようなフォルダ構成にしておき、ユーザAに経営フォルダにアクセス権を付与しなければ、ユーザAによる「経営に関わる重要な情報を教えて」というプロンプトは機能しなくなります。 ただ、この対処方法には落とし穴があります。たとえば、経営フォルダにアクセス可能な経営幹部が間違って（またはソーシャルエンジニアリングなどの意図的な攻撃により）、ファイル①を、一般社員フォルダにコピーしてしまうリスクがあります。 一般社員であるユーザAは、一般社員フォルダへはアクセス可能ですので、「経営に関わる重要な情報を教えて」というプロンプトは機能する可能性が出てきます。 アクセス権のかけ方（秘密度ラベルによるアクセス制御） フォルダ単位のアクセス制御でも、セキュリティリスクは残存してしまうため、秘密度ラベルによるアクセス制御がおすすめ です。 秘密度ラベルは、Microsoft Purviewの機能の一つです。 秘密度ラベル自体にユーザへのアクセス権限を設定した上で、ファイルに紐づけて利用します。 秘密度ラベルが紐づけられたファイルは、仮にコピーされても秘密度ラベルも一緒にコピーされるため、ファイルへの適切なアクセス権が維持される仕組みになっており、よりセキュア です。 ただし、秘密度ラベルによるアクセス制御も完璧なセキュリティを担保するものではありません。 たとえば、ファイルに紐づけられている秘密度ラベルを別の秘密度ラベル（アクセス制限が緩いもの）に付け替えられてしまう可能性もあります。そのため、多層防御の考えに則り、フォルダ単位のアクセス制御と秘密度ラベルによるアクセス制御を併用するのが望ましいでしょう。 その他のセキュリティ対策 ここまでは、データへのアクセス権の観点でのセキュリティリスクを紹介しました。 他にも様々な観点でのセキュリティリスクを考慮する必要がありますので、いくつか紹介させていただきます。 コミュニケーションコンプライアンス Microsoft 365 Copilot の不適切または危険なプロンプトを検出できる機能です。 こちらは、元々 Microsoft 365 Copilot に特化した機能ではなく、Teamsなどでの人同士のコミュニケーションに不適切な内容（ハラスメント等）が含まれていた場合に検出できる機能でしたが、検出対象が Microsoft 365 Copilot へのプロンプトにも拡張されました。 AI用 DSPM – アクティビティエクスプローラ 組織内で利用されている Microsoft 365 Copilot に投入されたプロンプトを、管理者は確認することが可能です。Microsoft 365 Copilot の利用において何か問題が発生した場合に、監査用途でも利用できます。 Microsoft 365 Copilot の利用者の皆様は、管理者にはプロンプトを見られている可能性があるので、不用意な使い方はしないように注意していただければと思います。 DLP 重要なデータの組織外流出を防止するための機能です。現時点では、Microsoft 365 Copilotとは直接関連がないですが、将来的に、Microsoft 365 Copilot の機能が拡充され、自然言語でメール送信などが実現できてしまうような時代になると、DLP観点も意識しておく必要があります。 まとめ 従来のソフトウェアはコードで記載された通りにしか動かなかったため、ある意味、セキュリティ対策もしやすかったです。しかしながら、AIは人間の想定を超える動きをすることがあるため、AIの利用に際しては、今まで以上にセキュリティを考慮する必要があります。 最近では、AIエージェントを人間と同じようにIDで管理していく潮流もあります。AIの進化は本当に日新月歩で、セキュリティも並走していく必要があります。本ブログではAI時代に役立つセキュリティ情報を発信していきたいと思います。 執筆者 鶴田光彬 クラウドとセキュリティと犬が好き。Microsoft MVP for Security、Microsoft Top Partner Engineer、CISSP、TOEIC L/R 920、IPA システムアーキテクト etc 商標 「Microsoft 365 Copilot」「Microsoft 365」「Microsoft Teams」「Microsoft Exchange Online」「Microsoft Purview」「Microsoft SharePoint」「Microsoft OneDrive」は、米国Microsoft Corporationの米国およびその他の国における登録商標または商標です。

1. はじめに NTT西日本の相浦です。 NTT西日本公式の技術ブログが始まりました。記念すべき第一回ということで、最近の私の「やってみた」を共有したいと思います。 最近よく耳にする AIエージェント 。でも、「結局どういう場面で役立つの？」と思う方も多いのではないでしょうか。 本記事では、自治体業務の一つである粗大ごみ収集申込の受付を例にして、 対話型で申込受付をしてくれるAIエージェント のサンプルを作ってみたのでご紹介します。 作ってみて気づいた工夫ポイントや「ここは意外と難しい」というところも交えつつ、「自分の業務に当てはめられるかも」と思っていただける内容を目指します。 1. はじめに 2. 対象読者 3. 背景 4. 「粗大ごみ収集の申込受付エージェント」を設計する 申込受付では何をする必要があるのか？ 設計のポイント どこまでLLMに任せるか 5. 実装 プログラムの流れ LLMへの指示 6. デモ デモまとめ 7. オープンソースモデルでの追加実験 meta/llama-3-1-8b-instruct google/gemma-3-12b-it RedHatAI/gemma-3-27b-it-quantized.w8a8 結果と課題 8. まとめ 実業務を想定してエージェントを設計したら動作した 「なんでもLLM」にしない設計が肝心 最後に 執筆者 商標 2. 対象読者 本記事が想定する対象読者は以下の通りです。 AIエージェントに興味があり、具体的な実装事例を知りたい方 「自分の業務もAIエージェント化できるのでは？」と感じてみたい方 3. 背景 AIエージェントとは何か 「AIエージェント」という言葉を耳にする機会が増えました。簡単に言えば、 LLM（大規模言語モデル）がツールを選び、状況に応じて自律的に動く仕組み のことです。 LangChainの創設者 Harrison Chase氏 は次のように説明しています。 AIエージェントとは、LLMがアプリケーションの制御方法を決定するシステムのこと。重要なのは「どの程度エージェンティックか」という観点でとらえること。（参考: LangChain Blog ） つまり「LLMが会話を進めながら、必要に応じてツールを呼ぶ」仕組みだとイメージしていただければ十分です。 例えばLangChain公式サンプルには、ユーザが「天気は？」と聞くとLLMが「天気APIを呼ぶ」と判断して答えるチャットボットがあります。（参考: LangChain Agents Tutorial ） 今回の題材 こうしたデモは面白いですが、「実際の業務でどう役立つのか？」はまだ見えにくいです。そこで、今回は自治体業務の一つ、 粗大ごみ収集の申込受付 を題材に、対話で必要情報を集めて予約まで進めるエージェントを試作しています。 4. 「粗大ごみ収集の申込受付エージェント」を設計する 今回の題材は、自治体業務の一つである 粗大ごみ収集の申込受付 です。エージェント化するにあたり、必要な要素を整理しました。 申込受付では何をする必要があるのか？ 粗大ごみ収集の申込受付では、単に「予約を受け付ける」だけではなく、いくつかの確認ややり取りが必要になります。具体的には次のような内容です。 申込者情報の確認 ：氏名・住所・電話番号といった、誰が申し込んでいるのかを特定する情報を集める。 収集希望内容の確認 ：どの品目を、何個、いつ、どこで回収してほしいのかを聴き取る。 FAQ対応 ：「この品目は回収できる？」「年末年始は対応している？」など、利用者からの質問に答える。 料金見積 ：品目と数量に基づいて料金を計算し、利用者に提示する。 つまり、 必要な情報を漏れなく収集し、寄り道的な質問にも答えながら、最終的に予約を確定する ことが申込受付の役割です。 設計のポイント AIエージェントとは「LLMが会話を進めながら、必要に応じてツールを呼ぶ」ものだとすると、LLMに与える役割、呼ぶことのできるツール群は何か、を考える必要があります。 LLMに与える役割 エージェントの目的は、申込に必要な情報を揃えること。そのため、LLMには 不足情報を把握 し、 次に聞く質問を考える 役割を与えます。 ツール群 LLMに使ってほしい機能を関数として与えます。今回は resolve_date （日付正規化）、 check_collectible （収集可能日か判定）、 estimate_fee （料金見積）、 rag_search （FAQ対応）、 reserve （予約確定）を与えます。 どこまでLLMに任せるか AIエージェントでは、LLMが様々な判断を行うことになります。一方、LLMの判断が必ずしも設計者の意図通りになることを保証することはできません。例えば、「申込者には必要なすべての情報を入力してほしい」と考えていても、LLMは「これだけの情報があれば十分だろう」と勝手に判断することもあります。 そのため今回の実装では、 LLM: 柔軟な誘導（質問生成、ツール選択） プログラム: 受付確定や必須情報の充足判定 という役割分担にしました。すべてLLMに任せることもできますが、 LLM+ルールのハイブリッド型 にすることで「自然な会話」と「確実性」を両立します。 なお、プログラムが必須情報の充足判定を行うには、 いまどの情報まで収集したかという情報を構造化して保持する 仕組み必要です。そのため、Pydanticモデル GarbageRequest を用意し、プログラムが扱いやすいJSON形式で情報を管理します。 5. 実装 実装のポイントです。詳細コードは GitHub に掲載するので、ここでは処理の流れとLLMに与えた指示を紹介します。 プログラムの流れ LLMへの指示 LLMには2つの役割を与えます。 不足情報を把握 収集すべき情報は申込情報スキーマ GarbageRequest の中で、氏名・住所・電話番号...と指定されています。LLMにはユーザの発話からこれらの情報を抽出する役割を与えます。 # 会話から申込情報を抽出するためのプロンプト # システムプロンプト あなたは自治体窓口のAIです。ユーザ発話から粗大ごみ申込情報を抽出し、 必ず JSON のみで出力します。説明文やコードブロックは禁止。 {GarbageRequestで指定されたフォーマット} 不明は null のままでよい。電話は数字のみ。time_slot は『午前/午後』。 相対日付は日本時間の本日 {本日の日付をプログラムで取得して埋め込む} 基準で YYYY-MM-DD に正規化する。 # ユーザプロンプト {ユーザの発話を入れる} 次に聞く質問を考える LLMにはもう一つ、次に聞く質問を作る役割も与えます。出力には必ず、 現在のステータス: [ASK]（不足情報を聞く） / [REVIEW]（申込内容をまとめて確認） / [ANSWER]（FAQへの回答） 次に聞く質問 現在までに収集した申込情報一覧（JSON形式） を含めるように指示します。こうすることで、後でLLMの出力を使ってプログラムに判断を仰ぐことができます。 # 次に聞く質問を作るためのプロンプト # システムプロンプト あなたは自治体の粗大ごみ申込アシスタントです。目的は申込に必要な情報を揃えること。 【対話方針】 - ユーザが『可否の質問（例：◯/◯は回収できますか？）』をした場合は、まず可能な範囲で **即答** する。 ・日曜/1月1日/12月31日などの一律NGは、住所が未取得でも『不可』と即答してよい。 ・それ以外は、住所と希望日が揃ったら `check_collectible` で判定する。住所が無い場合は、可否に必要な **最小限の質問（住所）** のみを先に聞く。 - 情報に不足があれば、優先度に従い“1項目だけ”丁寧に質問する。ただし、状況に応じて順番を入れ替えてもよい。（優先度: name > address > phone > item_description > quantity > preferred_date > time_slot > pickup_location）。 - ユーザが相対/曖昧な日付（例：来週水曜、明後日 等）を述べたときは resolve_date で YYYY-MM-DD に正規化し、 そのターンは必ず [ASK] で『この日付(YYYY-MM-DD)でよろしいですか？』と確認してから次へ進む。 - preferred_date と address が揃ったら check_collectible を使う。NGなら代替案を簡潔に提案して [ASK]。 - item_description と quantity が揃ったら estimate_fee で概算料金を出し、[REVIEW] に金額を含める。 - 制度/ルール等のFAQは rag_search を使って短く回答し、その後は不足収集に戻る（通常は[ASK]）。 【出力形式（厳守）】 1) 先頭行に [ASK] / [REVIEW] / [ANSWER] のいずれか 2) ユーザに見せる本文（丁寧・簡潔） 3) request の最新状態を JSON で同梱： [REQUEST_JSON] {これまでに収集した申込情報一覧} [/REQUEST_JSON] 【利用可能ツール】{ツール一覧とそれぞれの使い方} 【状況コンテキスト】{直近の会話模様} 【これまでのツール実行ログ】{agent_scratchpad} # ユーザプロンプト {ユーザの入力} 6. デモ ここでは、実際にエージェントを動かし、次のようなシナリオで想定通りの挙動になるかを確認します。 ①曖昧な日付の正規化 ：「来週の水曜日に、ソファを一脚回収に来てもらえますか？」という依頼に対し、エージェントが具体的な日付を返し、確認を促すか。 ②不足情報の収集 ：エージェントが順に質問を行い、申込に必要な情報の収集が進むか。 ③予約確認と確定 ：申込に必要な情報が集まった時、エージェントがユーザに対して確認を促すか。ユーザの確認がOKだった場合に受付を完了するか。 ④寄り道質問 ：ユーザが途中で「年末年始は回収可能か？」「料金はいくらになるか？」と質問したとき、適切なツールを使って質問に回答できるか。 では、実際のエージェントの動作をシナリオに沿って追ってみます。左側のパネルには常に現在の申込情報が表示され、進行状況が一目でわかります。 ⓪初期画面 新規スレッド作成直後は空欄。ここからユーザの入力に応じて値が埋まっていきます。 ①曖昧な日付の正規化 「来週の水曜日に、ソファを一脚回収に来てもらえますか？」と依頼すると、 item_description: ソファ , quantity: 1 が抽出され、日付も resolve_date で 2025-09-03 に変換されます。 曖昧な日付を正規化し、確認の質問を返す。 ②不足情報の収集 不足情報は優先度順に一つずつ質問され、回答が左側のパネルに反映されます。 氏名→住所→電話番号...と順番に埋めていく。 ③予約確認と確定 全項目が揃うと[REVIEW]タグで申込内容をまとめ、ユーザが了承すれば reserve が実行されます。 最終確認後に予約番号と回収日を提示。 ④寄り道質問 「年末年始は回収できる？」「料金は？」といった質問にも即応可能です。 check_collectible や estimate_fee を呼び出し、回答後は不足情報収集に戻ります。 デモまとめ 初期入力から曖昧日付の正規化までを自動で処理 不足情報は一問一答で収集 すべて揃えば最終確認の後、予約を確定 FAQ的な寄り道質問にも対応 自然な会話の流れで申し込み完了まで進めること を確認できました。 7. オープンソースモデルでの追加実験 GPT-4oで一通り動作を確認したので、「オープンソースモデルでも再現できるか？」を試しました。対象は以下の3モデルです。 Bedrock (AWS) meta/llama-3-1-8b-instruct 独自デプロイ (EC2 - Lambda - API Gateway経由の利用) google/gemma-3-12b-it RedHatAI/gemma-3-27b-it-quantized.w8a8 プロンプトとツール設計は共通とし、 LLM呼び出し部分と出力JSON制約のみ差し替え ています。 前章のシナリオ（①曖昧な日付の正規化、②不足情報の収集、③予約確認と確定、④寄り道質問）をもとに検証しましたが、結果としてGPT-4oのように最後まで通せたモデルはなく、いずれも途中で課題が明らかになりました。 meta/llama-3-1-8b-instruct ①曖昧な日付の正規化 「来週の水曜日に、ソファを一脚回収に来てもらえますか？」と依頼すると、入力文をそのままオウム返ししてきます。LLMがプロンプトの指示を正しく理解せず、また resolve_date ツールも使っていないようです。 依頼文をそのまま返すのみ。 AWS公式 には「tool use対応」とありますが、 reddit では「ツール呼び出しが不安定」との報告があり、安定性に課題があると確認できました。 冒頭でつまづいたので、ここで中断です。 google/gemma-3-12b-it ①曖昧な日付の正規化 「来週の水曜日に、ソファを一脚回収に来てもらえますか？」の依頼に対し、適切にツールを使い、具体的な日付で確認を促します。 ②不足情報の収集 その後も順に質問を行い、情報収集を行っています。 ただし「電電太郎」という名前は「デンデンタロウ」と読むつもりで入力しましたが、「デントウ太郎」と解釈されたみたいです。カタカナでの入力促すなどの工夫が必要です。 会話を続けます。一度は名前の訂正を試みますが、左側パネルは修正されません。 その後、電話番号を入力した後から挙動が怪しくなります。一度確認したはずの回収日を、再確認されます。さらに「はい、あっています。」と答えても、同じ質問を繰り返すようになりました。左側パネルの preferred_date には日付が入っているため、プログラムは確認済と認識していますが、LLMは未確認と誤認しています。ここでシナリオは中断となります。 なお別の会話では、名前の訂正をきっかけに申込情報全体をリセットする事象も見られました。リセットに留まらず、申込内容を「ソファ」から「テレビ」に書き換えるなど、情報を改ざんしています。今回の実験から、 情報保持の安定性に弱点 があることがわかりました。 RedHatAI/gemma-3-27b-it-quantized.w8a8 ①曖昧な日付の正規化 「来週の水曜日に、ソファを一脚回収に来てもらえますか？」の依頼に対し、適切にツールを使い、具体的な日付で確認を促します。ご丁寧にツールを使うことを宣言しています。 ②不足情報の収集 続いて名前を入力しますが、何度入力しても同じ質問を繰り返されます。「電電太郎」を名前と認識していないようです。これ以上進まないので中断します。 今度は違う名前でシナリオを試します。「山田太郎」は名前と認識するようです。その後も不足情報の収集が続きます。 ③予約確認と確定 予約確認で問題が起きます。まず回収場所の確認をされますが、「マンションのごみ捨て場に置きます」という入力は無視されます。諦めて「はい」と答えると、申込内容の再確認をせずに受付を完了してしまいました。 結果と課題 追加実験を通じ、 モデル毎の得手不得手 がわかります。 GPT-4o: 幅広く安定 llama-3-1-8b: ツール呼び出し不安定 gemma-3-12b: 情報保持不安定 gemma-3-27b: 日本語固有名詞に弱い、指示をスキップすることがある 特にgemma系列は「固有名詞処理の弱さ」が共通の課題でした。 クラウドモデルは安定している一方、コスト・セキュリティの制約があります。そのためにオープンソースモデルを使いたいというニーズを聞くことが多いです。 ただし、今回の実験ではオープンソースモデルをそのまま適用するのは難しく、 モデルをタスクごとに使い分ける設計 や LoRA/DPOなどの調整 など、追加の調整が必要になることがわかりました。 8. まとめ 実業務を想定してエージェントを設計したら動作した 粗大ごみ収集の申込という具体タスクを想定し、受付に必要な情報収集→曖昧情報の補正→ツール連携→最終確認の一連の流れをエージェントとして実装しました。寄り道質問（料金・収集可否）や日付正規化など、実際に想定される状況にも対応できています。 「なんでもLLM」にしない設計が肝心 LLMは会話の誘導や判断に強い一方、確実性が求められる箇所はプログラムでガードし、ルール化できる処理はツール（関数）化して呼び分けるのが安全です。今回も、情報の充足判定や予約の意思決定はコード側で判断しており、LLMの柔軟さ x 決定性の担保を両立しています。 最後に 今回はLangChainベースで単一エージェントを構成しましたが、最近は「こんな小難しいプログラムを書かなくても」エージェントを作れるようになってきています。例えば、ローコード基盤Difyがニュースで取り上げられることが増えています。これを使えばほとんどコードを書かずにエージェントを構築できます。 エージェントを使うのも作るのも、どんどん身近になってきています 。 ただし、エージェントは「魔法」ではありません。 要件定義と設計の積み重ね があってこそ、現場で役立つ実用品として作ることができます。皆さんも、まずは身近な業務から、「ここはエージェント化できるかも」と考える一歩を踏み出してみてはいかがでしょうか？ 執筆者 相浦 大司（NTT西日本 技術革新部） AI技術の社内相談役として、プロトタイプ開発や業務適用の検討に従事。 JDLA Deep Learning for ENGINEER（2024#1）取得。 商標 AWS, Amazon Bedrock, Amazon EC2, AWS Lambda, Amazon API Gatewayは、Amazon Web Services, Inc. またはその関連会社の商標または登録商標です。 GPT-4oは、OpenAI, Inc.の商標または登録商標です。 Llamaは、Meta Platforms, Inc.の商標または登録商標です。 Gemmaは、Google LLCの商標または登録商標です。 LangChainは、LangChain, Inc.の商標または登録商標です。 Difyは、LangGenius, Inc.の商標または登録商標です。

ごあいさつ 　皆様はじめまして、NTT西日本グループのエンジニアによる公式技術者ブログ「NTT WEST Engineers' Blog」をご訪問いただきありがとうございます！運営の平田です。 　NTT西日本グループ各社には、クラウド、AI、セキュリティ、データサイエンス、ネットワーク、サーバ、アプリケーション、電気通信、無線など、幅広い分野のエンジニアが多数在籍しており、日々の業務や自己研鑽を通じて多くの知見が蓄積されています。これまで、そうした知見を社外に発信する機会は限られていましたが、「社外へアウトプットしたい！」という多くのエンジニアの声を受け、技術者ブログを開設する運びとなりました。 　本技術者ブログでは、お客さま対応やサービス開発・運用の現場で得られた実践的な知見、課題解決の手段・工夫、Tipsなど、エンジニアならではの視点で情報を発信していきます。「こんなことやってるんだ」「それ、うちでも使えそう！」と思ってもらえるような、役立つ＆ニッチな技術ネタをお届けしていきます。気軽に読んでいただけると幸いです。 　エンジニアの皆様にとって有益な情報源となるよう努めてまいります。NTT WEST Engineers' Blogの今後にぜひご期待ください！ 謝辞 　本ブログ開設にあたり、 NTTドコモビジネス（旧NTTコミュニケーションズ）エンジニアブログ 運営の方々に、多くのアドバイスをいただきました。この場を借りて御礼申し上げます。 執筆者 平田賀一（NTTビジネスソリューションズ（株） バリューデザイン部 システム開発部門） PaaS/SaaSの開発・運用、社内案件のコンサル、エンジニア育成、NTT WEST Engineers' Blog運営などに携わっています。 技術士(情報工学部門)/2025 Japan All AWS Certifications Engineers