Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して

Avatar for os1ma os1ma
July 31, 2025

Claude Codeが働くAI中心の業務システム構築の挑戦―AIエージェント中心の働き方を目指して

Claude Codeをはじめとするコーディングエージェントの盛り上がりは凄まじく、ソフトウェア開発でのさまざまな活用事例が出てきています。

実はClaude Codeなどのコーディングエージェントは、ソフトウェア開発以外のタスクにも活用することができます。

実際に登壇者は、Claude Codeを中心として実業務のタスクを管理・遂行することに挑戦しています。

この勉強会では、Claude Codeを汎用エージェントとして活用し、AIに実業務のタスクを管理・遂行させるシステムの構築について紹介します。

AIエージェントが実業務のタスクを管理し、できる限りAIエージェント自身で遂行し、必要に応じて人間に助けを求める... そんなAIエージェント中心の働き方をつくる試みについてお話しします。

---

・イベントページ:https://studyco.connpass.com/event/361662/
・アーカイブ動画:https://youtube.com/live/6Y1zFCa2e-A

Avatar for os1ma

os1ma

July 31, 2025
Tweet

More Decks by os1ma

Other Decks in Technology

Transcript

  1. 会社名 株式会社ジェネラティブエージェンツ (英文:Generative Agents, Inc.) 所在地 東京都港区 ※ 全社員リモート勤務 役員構成

    CEO 西見 公宏 COO 吉田 真吾 CTO 大嶋 勇樹 設立年月 2024年3月14日 事業内容 AIエージェント技術を軸とした生成 AIアプリケーション開発 支援、コンサルティング、教育・研修サービスの提供 AIエージェントインテグレーションサービスの提供 AIエージェントを実業務で本当に活用するためには、AIエージェントの技術特性 と問題解決領域の両面から検討を進める必要があります。当社は「LangChain」 の公式エキスパートとして、AIエージェントを開発するための確かな技術力を活 かし、生成AIアプリケーション開発支援からコンサルティング、教育・研修サービ スまでのあらゆる方面において、AIエージェントを活用した問題解決サービスを 提供します。 インテグレーションを支えるサービス群の提供 AIエージェントを効果的に運用するためには、AIエージェントを動かすためのイ ンフラが必要です。当社はマルチエージェントのオーケストレーション基盤である 「Generative Workforce(※開発中)」をはじめ、AIエージェントのためのツール群 「middleman.ai」の提供を通して、AIエージェント活用のための基盤構築をサ ポートします。 株式会社ジェネラティブエージェンツ - 会社概要 AIエージェントが「ハブ」となり 人間とAIエージェントの協働が 当たり前になる世界を実現する
  2. コーディングの手順を指示としてまとめる 特定の流れでコーディングしてほしい場合、その手順を指示としてまとめておく場合があります # 実装手順 1. 今回の実装と関連する箇所の 既存のコードを確認する 2. コードを実装する 3.

    uv run pytestでテストを実行する : 必要に応じてコマンドの 実行を指示することも可能 実装の手順を指示としてまとめておいて実行させるのと同じように、 ソフトウェア開発以外のタスクも手順をまとめておいて実施させることができます
  3. 業務マニュアルに従って仕事をさせる 1年前と異なり、具体的な業務マニュアルとツールがあれば、 汎用エージェントがある程度の業務をこなすことが可能になってきています # ◯◯業務マニュアル ## 手順 1. … 2.

    … 3. ◯◯コマンドを実行してデータを 登録する : コーディングエージェントを、独自のツールを与えたりしやすい カスタマイズ可能な汎用エージェントとして活用するということです ツール(スクリプト)を実装しておけば、 任意のAPIを操作させることが可能
  4. ソースコードリポジトリの活用 ChatGPTなどのサービスではなくコーディングエージェントを使う大きな理由の1つは、 ソースコードリポジトリとの相性が良いことです たとえば以下のようなディレクトリ構成で各業務のマニュアルやツール(スクリプト)を管理します . ├── operations │ ├── README.md

    ... 業務一覧 │ ├── operation_1 │ │ └── README.md ... 業務1のマニュアル │ └── operation_2 │ └── README.md ... 業務2のマニュアル └── scripts ... エージェントのツール ├── google_drive.py └── google_sheets.py • 業務マニュアルやツール自体も コーディングエージェントに書かせる • コーディングエージェントが想定外の ファイルの編集をすることも多いので、 Git・GitHub等の利用は重要
  5. (補足)MCPを使う?コマンドを実行させる? コーディングエージェントを活用するうえでは、MCPが適しているケースもあれば、コマンドを実行 させることが適しているケースもあります MCPを使うケース コマンドを実行させるケース • 既存のMCPサーバーがサポートして いる操作をさせたい場合 • ツールの存在を常に伝えておいて、

    エージェントの判断によって適宜 使わせたい場合 • 既存のMCPサーバーがサポートして いない操作をさせたい場合 • ツールの存在を常に伝えておく必要 はなく、どの場面でどのコマンドを 使うのか適宜明確に指示する場合 ツールがたくさんある場合、MCPで多数設定してエージェントの判断で使い分けさせるよりも、 実行してほしいコマンドをその場その場で明確に伝えたほうが挙動が安定しやすいと考えています
  6. 本当にAIエージェントに求めていること たとえば、StudyCoのような勉強会コミュニティを運営するうえでも、さまざまな業務があります • 勉強会の企画を考える • connpassのイベントページを作成・公開する • YouTubeの配信設定をする • 登壇資料を作成する

    • アーカイブ動画を公開する • お問い合わせがあれば返信する • etc… 通常はこれらの業務を人間がタスク管理して遂行しています 本来であれば、AIがタスクを管理して、AIにできることはAIがやって、 人間はAIに言われた(AIだけで完結できない)タスクだけやるべきです
  7. LangChainが提唱する「Ambient Agents」 LangChainでは、イベントに応じて動作するエージェントを 「Ambient Agents」と呼んでいます Ambient Agentsは、イベントをもとに起動して、必要に応じて人間に対する 通知・質問・レビューのアクション(Human-in-the-Loop)を実施します イベント 必要に応じて人間に

    通知・質問・レビュー エージェントが できる範囲の処理 https://blog.langchain.com/introducin g-ambient-agents/ トリガー カスタマーサポートのチケットシステムのように、 人間の対応すべきタスクを一覧化して、 人間はアサインされたタスクを順にさばいていく Agent Inbox 初手AI
  8. HumanLayerの「Outer Loop」 HumanLayerは、エージェントのループの中で人間を呼び出すことを「Outer Loop」と表現しています https://github.com/humanlayer/humanlayer 人間が指示してAIが働くのではなく、AIが指示して人間が働くという考え方です • 第1世代:Chat 人間の質問に答える •

    第2世代:Agentic Assistants 人間の指示に対してエージェントがループする (ツール利用などのループ) • 第3世代:Autonomous Agents エージェントのループの中で人間を呼び出す 「Outer Loop」
  9. Claude Codeの可能性 Claude Codeであれば、イベントをもとに簡単にエージェントを起動できます ChatGPTやIDE型のコーディングエージェント → 作業の指示は人間が出す必要がある Claude CodeのようなCLI型のコーディングエージェント →

    プログラム的に簡単に実行できる CLI型のコーディングエージェントを使うことには、 以下のようなメリットもあります • AIエージェントを自前で実装するのと異なり、 ファイル編集などの機能が予め提供されている • ローカル環境でもリモート環境でも同じように 動かすことが可能なため何かと便利
  10. 「タスク」はLLMエージェントの世界のファーストクラスオブジェクト LLMエージェントが動作する基盤を設計するうえで、「タスク」は重要な概念だと考えています A2A(Agent2Agent)でも、「タスク」はコアな 概念として定義されています > Task: The fundamental unit of

    work managed by A2A, identified by a unique ID. Tasks are stateful and progress through a defined lifecycle. 「タスク」はA2Aで管理される作業の基本単位 https://a2a-protocol.org/latest/specification/#2-core-concepts-summary 「タスク」に対して人間やエージェントの会話履歴(List[Message])がひもづくという考え方が A2AやAIエージェントの各種フレームワークで見られます
  11. 構成例:Zapier x GitHub x Claude Code イベント GitHub Issues タスク管理システム

    Claude Code エージェント GitHubリポジトリ 業務マニュアル・ ツール(スクリプト) Zapier Webhook イベントが発生したら タスクが登録される タスクが登録されたら エージェントが起動して処理する 参照・使用 アサインされている タスクを実施する 必要に応じてタスクに 人間をアサインして対応依頼 GitHub Issueの作成をトリガーとして、GitHub ActionsでClaude Codeを実行するようなイメージです ※実際にこの用途でGitHub Actionsの利用を検討する場合は後述する利用規約に関する注意があるため、Webhookを使う構成としています
  12. (注意)GitHub Actionsの利用規約 GitHub Terms for Additional Products and Features https://docs.github.com/en/site-policy/github-terms/github-terms-for-additional-products-and-features

    > ・Any activity that places a burden on our servers, where that burden is disproportionate to the benefits provided to users (for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden); or > ・If using GitHub-hosted runners, any other activity unrelated to the production, testing, deployment, or publication of the software project associated with the repository where GitHub Actions are used. ・私たちのサーバーに負荷をかける活動で、その負荷がユーザーに提供される利益に対して不釣り合いなもの(例えば、Actionsを コンテンツ配信ネットワークとして、またはサーバーレスアプリケーションの一部として使用しないでください。ただし、低い利 益のActionでも、負荷も低い場合は問題ありません);または ・GitHub-hostedランナーを使用している場合、GitHub Actionsが使用されているリポジトリに関連するソフトウェアプロジェクト の本番、テスト、デプロイメント、または公開に関係のないその他の活動。 (Claude Sonnet 4による日本語訳)
  13. Step1. 対象とする業務領域を決める まずは対象とする業務領域を決める必要があります 非定型的な業務が多い領域よりも、定型的な業務が多い領域のほうが適用しやすいと考えています 適用の難易度が高そうな業務領域 適用しやすそうな業務領域 • ソフトウェアの新規開発 • 新規事業の立ち上げ

    → いわゆるプロジェクト型の業務 • 週次・月次の社内業務の対応 • テクニカルサポートサービスの提供 → いわゆる定常業務・半定常業務 ソフトウェア開発関連では、運用業務などには適用しやすいかもしれません
  14. Step2. 業務一覧を作成する 対象の業務領域を決めたら、業務一覧を作成します その際、各業務はいつ実施するのかトリガーを明確にする必要があります # 勉強会コミュニティの運営業務一覧 - 勉強会の企画を考える(2週間に1回実施) - connpassのイベントページを作成・公開する(企画が決まったら)

    - YouTubeの配信設定をする(イベント当日) - 登壇資料を作成する(イベントの1週間前に人間に指示) - アーカイブ動画を公開する(イベント翌日) - お問い合わせがあれば返信する(Google Formからお問い合わせがあった際) - etc…
  15. Step3. 業務の起点をAIエージェントにする 業務一覧をもとにその日のタスクを登録するエージェントを実装します また、何らかのイベントをもとにタスクが登録される仕組みも実装します # 業務一覧 - … - …

    - … タスク管理システム 日次タスク登録 エージェント エージェントが 起動して タスクを処理 最初は「この業務を人間に依頼する」 という処理をさせるだけでもよい イベント タスクを登録 このようにして、エージェントがタスクを管理して、一次処理する仕組みをつくることができます 今日のタスクを 判断 補足 • すべてをAIエージェントで実装する 必要はないため、ルールベースで 実装可能な箇所はルールベースでOK • エージェントにタスクを登録させる 機能を持たせる場合、エージェントが タスクを登録しては起動し続ける 無限ループに注意が必要
  16. Step4. 各業務のマニュアルと必要なツールを作る 各業務のマニュアルと必要なツールをひたすら作成します # 業務一覧 - … - … -

    … # ◯◯業務マニュアル ## 手順 1. … 2. … 3. ◯◯コマンドを実行する : 「大変では?」と思うかもしれませんが、 実際なかなか大変です ただし、コーディングエージェントを駆使すれば、 手作業で実施するような大変さではありません 音声入力の活用もおすすめです ツール(スクリプト)
  17. (3/5)チューニングは評価駆動で 評価としては、チューニングが必要なタスク(業務)に対して自動オフライン評価を実装しています 現時点でオフライン評価を網羅的に実施していない理由 • 自分が業務マニュアル(プロンプト)を書いて 目の届く範囲で使用しているため、うまく動作 しなかったとしても自分がカバーすれば解決する • 各種ツールのモックが必要であるなど、評価の 仕組みを構築するコストが高いため、現時点では

    簡単なタスクから難しいタスクまで一律で評価を 整備するのは費用対効果が悪い しっかりチューニングしたいタスクについては、 評価を実装してからチューニングしています • LangSmithを使用してClaude Codeの処理を オフライン評価してチューニング • うまく動作しなかった例に対して、人手で Ground Truthを作成してデータセットに使用 • 外部APIを呼び出すツールはモックを用意し、 評価の際のみモックを使用する仕組みを構築 今後より多くのタスクを任せて継続的に運用し続けると、評価を整備しないとリスクが高まるため、 評価をできるだけ簡単に整備するための仕組みも検討中です 一方で...
  18. (5/5)業務システム開発の知見を活かす 実は今日のテーマは、 「AI中心の業務システムの開発」 の話だと言えます 当初の仮説 • 業務マニュアルとツールがあれば、AIエージェントに多くの業務を遂行させられるのでは? 実際に取り組んでみて • 業務プロセスを中心に考えるだけでは例外対応が複雑すぎる

    → データを中心に整理してみる 「AI中心の業務システム」というものが今後盛り上がる可能性があると考えています 「AI中心の業務システム」を開発するうえでも、通常の業務システムの開発の知見が役立ちそうです
  19. 今後の展望 今回紹介したシステムはある程度動き始めたものの、まだまだ取り組むべき点はたくさんあります • Claude Codeを単純に実行するだけでは難しい処理への対応 Human-in-the-Loopなど • より高度なタスクを担わせるための認可やセキュリティ面の対応 チームでこの仕組みを活用する際の制御など •

    この仕組みを簡単に構築できるプラットフォーム(インフラ)の開発 うまくいく見込みが立てば、様々な業務をこの仕組みに載せていきたい 今回お話ししたような「AI中心の業務システム」をかたちにして、そのインフラをつくっていきます