みなさんこんにちは！関西で製造業のお客様を中心に技術支援をしているソリューションアーキテクトの河井です。今年も AWS Summit Japan 2026 の季節がやってまいりました！会場は千葉県の幕張メッセです。今年も製造業向けの展示を出展する予定ですので、ぜひ遊びに来てください。AWS Summit の概要と製造ハイライト展示の見どころは こちらのブログ に掲載していますのでご覧ください。 本ブログではハイライト展示内の Supply Chain ブースの展示について紹介します。今回のブースでは、サプライチェーンの意思決定を AI で加速する 2 つのアプローチを展示します。1 つ目は AWS のサービスを組み合わせて作る AI エージェントを活用したアプリケーション で、マーケットサインを起点に需要予測から生産計画提案までを一気通貫で実行するデモです。2 つ目は SaaS 形態でサプライチェーンの Decision Intelligence (DI) をエージェントとして提供する Amazon Connect Decisions で、サプライチェーン上で発生している問題を自動検知し、AI が根本原因の分析と推奨アクションを提示するマネージドサービスです。それぞれ異なるアプローチでサプライチェーンの意思決定を加速する様子をご覧いただけます。 製造業が直面するサプライチェーンの課題 製造製造業のサプライチェーンを管理する方々の頭を悩ませる課題は多くありますが、ざっくりとまとめると下記のように分類できるのではないでしょうか。 需要変動の兆候を掴んでも、定量化できない：  政策発表や市場トレンドの変化を感じても、「実際にどれだけ需要が増えるのか」を定量的に見積もれません。結果として対応が後手に回ります。 需要変動への対応に時間がかかる：  需要が急変したとき、在庫・生産キャパ・部品調達の見通しを確認するために、営業、生産管理、調達部門など様々な部署からの情報が必要で数日かかります。 物流の不確実性： 海上交通を使う場合はコンテナ不足・港湾混雑など予期せぬ問題が発生する可能性があります。そのほかにも地政学的リスクなどにより、輸送のリードタイムが突然倍増し、供給計画が崩れます。 在庫配分の判断の難しさ： 限られた在庫を複数の製品ラインにどう再配分するか、人手では即座に最適解を出せません。 これらの課題に共通するのは、「 情報はあるのに、それを統合して迅速に意思決定する仕組みがない 」 ということです。 AWS サービスを組み合わせた アプリケーションの概要 本デモでは、架空のドローンのメーカー「AnyCompany」（横浜工場）を題材に、マーケットサイン（政府のインフラ点検プロジェクト閣議決定）を起点として、AI エージェントに分析を依頼するだけで以下を一気通貫で提示する仕組みを体験いただけます。 需要予測 — 過去の受注履歴と公共入札件数から、今後 6 ヶ月の需要を予測 在庫・供給状況の可視化 — 現在の在庫水準、サプライヤー別の供給力、コンテナ不足の影響を即座に一覧化 増産シナリオ別の生産計画提案 — 需要予測の各シナリオに対して、3 製品間の生産配分最適化と売上影響を計算 総合提案 — 時間軸別（即時/短期/中期）の具体的なアクションリストを提示 従来なら数日かかる「需要変動への対応策立案」を、AI エージェントへの一言の依頼で数分に短縮します。 （需要予測） （増産シナリオ別の生産計画の提案） AI でどのように解決するのか このデモのアプローチは 3 つのステップで構成されています。 ステップ1：不確実な需要を「数字」に変える 市場の変化を感じても「増えそうだ」という感覚のままでは動けません。時系列基盤モデルが過去の受注履歴と外部指標（公共入札件数）を組み合わせて、「月 180 台（+50%）」のように確率区間付きで需要を予測します。これにより、感覚ではなくデータに基づく判断が可能になります。 ステップ2：制約の中で「何ができるか」を即座に計算する 需要が増えても、部品の供給制約や在庫水準によって実際に対応できる範囲は限られます。AI エージェントが在庫・供給データを取得し、複数製品間の生産配分を利益率・季節需要・納期制約を考慮して最適化します。 ステップ3：段階的な対応策を提示する 「まず生産配分の見直しで即座に対応（追加コストゼロ）→ 需要が上振れしたら追加調達」という段階的な提案により、過剰投資を避けつつ機会損失も防ぎます。AI エージェントがサプライヤー情報や過去の調達実績を検索し、具体的なコスト・リードタイムを含めた調達オプションを提示します。 使用している技術要素 Amazon Bedrock AgentCore Amazon Bedrock AgentCore は、AI エージェントの構築・デプロイ・運用を統合的に提供するプラットフォームです。エージェントにツール・メモリ・データを装備し、複雑なワークフローを処理させることができます。インフラ管理は不要で、セキュアかつスケーラブルなランタイム上でエージェントを実行できます。本デモでは、AgentCore 上に構築したエージェントが担当者の自然言語での依頼を理解し、需要予測の呼び出し → 在庫データの取得 → シナリオ計算 → Knowledge Base 検索を自律的にオーケストレーションします。従来であれば複数部門にまたがっていた確認作業を、1 つのエージェントが一気通貫で実行します。 Chronos-2（時系列基盤モデル） Chronos-2 は Amazon が開発した時系列予測の基盤モデルです。単変量・多変量、さらに影響を及ぼすその他の要因（共変量）を含む予測タスクを、追加学習なしで処理できます。グループアテンション機構により、複数の関連する時系列間で効率的に情報を共有し、高精度な予測を実現します。本デモでは、産業用ドローンの月次受注数（ターゲット系列）とインフラ点検関連の公共入札件数（共変量）を入力として、今後 6 ヶ月の需要を確率区間付きで予測します。単なるトレンド延長ではなく、外部要因の影響を反映した予測が可能です。 Amazon Bedrock Knowledge Bases Amazon Bedrock Knowledge Bases は、RAG（Retrieval Augmented Generation）ワークフローをフルマネージドで提供する機能です。データの取り込みから検索、プロンプト拡張までを、カスタム統合やデータフロー管理なしで実現します。本デモでは、サプライヤー別の基本情報（所在地・供給シェア・リードタイム）、部品仕様、過去の調達実績（増量交渉の実績・コスト増の目安）、航空便切り替え時のコスト情報を格納しています。AI エージェントがシナリオ分析の中で調達オプションを提示する際に、これらの情報を検索して正確な根拠に基づいた提案を行います。 これらの技術要素が同一プラットフォーム（AWS）上で動作するため、予測結果をエージェントに渡すための API 変換レイヤーや、Knowledge Bases へのアクセスのための認証統合を個別に設計する必要がないのも良いところです。IAM による統一的なアクセス制御のもと、エージェントが各サービスをネイティブに呼び出せます。 （アーキテクチャ図） ここからは、サプライチェーンの問題検知と対応を継続的に行うためのマネージドサービス、Amazon Connect Decisions を紹介します。 Amazon Connect Decisions コンセプト：発生した問題を即座に捉え、原因分析から対応策までを自動で提示する サプライチェーンの現場では、在庫不足・供給遅延・需要との乖離といった問題が日々発生します。これらの問題に対して、従来は担当者がデータを突き合わせて原因を調査し、対応策を検討する必要がありました。Amazon Connect Decisions は、この「問題の検知 → 原因分析 → 対応策の提示」という一連の流れを AI で自動化します。 検知（Detection） — あらかじめ定義したメトリクスとルール（例：「在庫カバー日数が 15 日を下回ったら」）に基づいて、サプライチェーン上の問題を自動的に検知します。 洞察（Insight） — 検知された問題に対して、AI が根本原因を分析します。例えば「2025 年に発注した入庫注文 2 件（計 5,169 EA）が未受領のまま 200 日以上経過し、補充パイプラインが完全に途絶している」といった具体的な原因特定を行います。 推奨アクション（Recommendation） — 分析結果に基づき、「発注書作成：17,105 EA」「サプライヤーパフォーマンスレビューの実施」「未受領注文の調査」といった具体的な対応策を優先度付きで提示します。 主な機能 Insights（問題の検知と分析）： ビジネスルールに基づいてサプライチェーンの問題を検知し、 AI が根本原因の分析と推奨アクションを生成します。ユーザーは自社のオペレーションを記述した S&OP を AI に読み込ませて「ガイドライン」を設定します。 Demand Planning（需要予測）： Amazon が培ったノウハウを組み込んだ AI/ML モデルが、過去の販売実績から自動的に需要予測を生成します。少ない履歴データでも初日から利用可能です。営業見込み・顧客コミットメントなど複数部門からのインプットを 1 つの合意予測（Consensus Plan）に統合する仕組みも備えており、AI Teammate（自然言語インターフェース） に「なぜこの予測値になったのか」と聞いて根拠を確認することもできます。 Supply Planning（供給計画）： 需要予測や受注データをもとに、素材の利用可能性・リードタイム・生産キャパシティ・倉庫スペースといった現実の制約を考慮した供給計画（生産・調達スケジュール）を生成します。計画の定期実行スケジュールも設定でき、プランナーが計画を調整・確定したうえで下流プロセスへ公開できます。 （ Insights の検出） （根本原因と推奨アクション） まとめ サプライチェーンの意思決定には、大きく 2 つの局面があります。1 つは市場の変化や突発的な事象に対して「次にどう動くか」を素早く判断する局面。もう 1 つは、日々発生する在庫不足や供給遅延といった問題に対して「いま何が起きていて、どう対処すべきか」を把握し続ける局面です。本ブースでは、前者に対しては AI エージェントがマーケットサインから需要予測・生産計画提案までを一気通貫で実行するデモを、後者に対しては Amazon Connect Decisions が問題を自動検知し、根本原因の分析から推奨アクションまでを提示するデモをお見せします。 注文を待ってから動くのではなく、不確実な時点から先手を打つ。問題が大きくなってから調査するのではなく、発生した瞬間に原因と対応策を手にする。この 2 つのアプローチで、ビジネスのアジリティを強化します。あなたのビジネスへの次の装備となるこの AWS Summit のサプライチェーンブースのデモを、ぜひ体験しに来てください。 著者について 　河井信彦（Nobuhiko Kawai） アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト セキュリティベンダーを経て AWS Japan に入社し、エンタープライズ技術本部でソリュー ションアーキテクトとして活動中。関西の製造業のお客様を中心担当している。趣味はサッカーとフットサル。

こんにちは。メルペイでソフトウェアエンジニアをしている @sapuri です。この記事は Merpay & Mercoin Tech Openness Month 2026 の 9日目の記事です。 はじめに 本記事は、2026年4月27日の Background Job Talk 〜 Temporal 活用と独自実装の舞台裏編〜 で発表した「内製ワークフローエンジンの設計とメルカリでの活用事例」を記事化したものです。 マイクロサービスアーキテクチャのような分散システムでは、複数のサービスにまたがる処理のデータ整合性をどう保つか、いわゆる分散トランザクションの扱いが大きな課題となります。 メルカリでは、この課題を Saga パターンによる結果整合性で解決するために、自社でワークフローエンジンを開発して運用しています。 このワークフローエンジンは、もともとメルコインの決済基盤における分散トランザクション管理のために開発したものです。メルペイの Payment Service で得た知見も取り入れながら設計し、現在はメルカリグループ内の複数のユースケースで利用が広がっています。 この記事では、内製に至った背景とワークフローエンジンの具体的な設計、社内での活用事例について紹介します。 分散トランザクション管理の課題と Saga パターン メルカリでは主にマイクロサービスアーキテクチャを採用しています。 そのため、お客さまがアプリで1つの操作をすると、そのリクエストは基本的に複数のサービスをまたいで処理されます。 例えば、メルカリアプリからビットコインを購入するときの決済リクエストでは、取引データの作成、メルコインの日本円残高の減算、メルペイのポイントの減算、ビットコイン残高の加算、取引データの更新といった複数の処理が関わります。 この決済リクエストは、1つのトランザクションとして扱う必要があります。つまり、一連の処理をすべて成功させるか、すべて失敗させるかのどちらかに寄せる必要があります。 しかし、各サービスがそれぞれデータベースを持っているため、単純にロールバックすることはできません。この点を考慮せずに実装すると、エラーのタイミングによってデータの不整合が発生します。 例えば、このような不整合が起こりえます。 決済が失敗したのにメルコインの日本円残高が減っている 残高は減ったがビットコイン残高が加算されない ビットコインと交換できているのに取引が完了扱いになっていない また、Two-Phase Commit のような分散トランザクションでは長期間リソースをロックするため、サービスの可用性が下がる可能性があります。 そのため、メルカリでは結果整合性のアプローチで、このような分散トランザクションを解決しています。 Saga この結果整合性を実現するためのアーキテクチャの1つとして、Saga というパターンがあります。 Saga は、トランザクションを複数の小さなトランザクションに分割して順次実行することで長時間のロックを不要にします。途中でリトライ不可能なエラーが出た場合は、成功済みの処理に対する補償トランザクションを逆順で実行します。 先ほどの暗号資産購入の例で、途中のビットコイン残高を増やす処理でリトライできないエラーが発生した場合を考えます。 この場合、この時点までに成功した処理を取り消す補償トランザクションを逆順に実行します。すでにメルコインの残高とメルペイのポイントが減らされているので、まずポイントを戻し、その次にメルコイン残高を戻し、最後に取引データを失敗として更新します。 このように実装することで、途中のどこで失敗しても結果整合性を保って処理を完了させることができます。 このあたりの話は以前の記事でも紹介しているので、興味のある方はそちらもぜひご覧ください。 メルコイン決済基盤における分散トランザクション管理 | メルカリエンジニアリング ワークフローエンジンの検討 実装の方針が決まったので、実際に Saga パターンを実装するためにワークフローエンジンの導入を検討しました。 主に検討したツールは、 GCP Workflows 、 Cadence 、 Temporal です。メルカリでは主に GCP を使ってサービスを構築しているため、まず GCP Workflows を検討しました。ただ、各処理を HTTP のエンドポイントとして実装する必要があり、ユニットテストがやりにくいという懸念がありました。また、YAML ではなく Go のコードでワークフローを記述したいという要望もありました。 Cadence と Temporal も検討しましたが、メルカリでは Cloud Spanner をメインに使っているため、Spanner に対応していなかったことから採用できませんでした。また、Temporal はシステムの規模が大きく、仕組みも比較的複雑なため、運用面にも不安がありました。 このように、既存ツールでは要件を満たせなかったため、自社でワークフローエンジンを開発することにしました。 開発時には、Cadence / Temporal のインターフェースの良さを取り入れつつ、メルペイの Payment Service ですでに実績があった「DB への実行状態の永続化 x インメモリキュー x Worker での実行管理」のアーキテクチャを再利用する方針にしました。また、Go 専用で必要な機能のみに絞ることで、数人の兼務メンテナーでも運用できる規模にしています。 ワークフローエンジンの設計 アーキテクチャ このワークフローエンジンは、アプリケーションサーバーと同じ Pod でデプロイされることを想定しています。 Go runtime で動作し、利用者は SDK として扱います。 アプリケーションは Manager というインターフェースを使ってワークフローエンジンを操作します。主に Register と Execute という2種類のインターフェースを使います。 アプリケーションはワークフローを普通の Go の関数として実装するので、その関数の内容を事前にワークフローエンジンに登録する必要があります。 manager.RegisterWorkflow() が呼び出されると、Manager は Registry というインメモリの領域に関数を格納します。 manager.Workflow().Execute() は、実際にワークフローを実行するインターフェースです。 呼び出されると、Manager は Engine Server という gRPC サーバーに対して Workflow や Activity を作成するリクエストを送ります。 Engine Server は関数名や引数、実行状態を DB に保存し、インメモリキューである Channel に WorkflowStarted イベントを publish します。 その後、Worker という goroutine が WorkflowStarted イベントを subscribe し、Registry から実行する関数を取得して、Go のリフレクションを使って実行します。 実行が完了すると Worker は Engine Server に完了を報告し、Engine Server は結果を保存して WorkflowCompleted イベントを publish します。 その後、Worker が WorkflowCompleted イベントを subscribe し、アプリケーションに関数の実行結果を返却します。 もしその結果がエラーだった場合は、後述する ErrorMarshaler というインターフェースで、その Workflow を完了させるかどうかを判定します。 ここまで説明したコンポーネントの役割を整理します。 Manager : SDK のエントリーポイント。アプリケーションは Workflow() 、 Activity() 、 RegisterWorkflows() などを呼び出します。 Engine Server : Create、Complete、List などの gRPC API を提供するサーバー。DB に Workflow や Activity の I/O と状態を保存します。 Channel : Workflow や Activity の状態遷移イベントのハブとなるインメモリキュー。 Workers : Workflow や Activity を実行する goroutine 群。Channel から状態遷移イベントを購読し、イベントの種別に応じた処理を実行します。 Registry : Register された関数をインメモリで保持します。 Recovery Worker : Engine Server に対して定期的に未完了の Workflow と Activity を List してリトライします。 コードサンプル アプリケーション側の実装イメージは次のようになります。 func (s *Service) createExchangeWorkflow(ctx context.Context, params *CreateExchangeParams) (*CreateExchangeResult, error) { saga := workflow.NewSaga(s.wm) if err := s.wm.Activity(s.authorizeBalance, params.Balance).ExecuteWait(ctx); err != nil { return nil, err } saga.AddCompensation(s.cancelBalance, params.Balance) if err := s.wm.Activity(s.authorizePoint, params.Point).ExecuteWait(ctx); err != nil { if !isCompletableError(err) { return nil, err } if cerr := saga.Execute(ctx, func(e execution.Execution) error { return e.Wait(ctx) }); cerr != nil { return nil, fmt.Errorf("failed to execute compensation activities: %w, orig_err: %v", cerr, err) } return nil, err } return &CreateExchangeResult{}, nil } まず、 createExchangeWorkflow という関数が定義されています。 この関数は、残高を確保する authorizeBalance という Activity と、ポイントを確保する authorizePoint という Activity を順に実行して結果を返す処理です。 特徴的なのは、それぞれの Activity を実行した直後に、この SDK が提供する Saga の AddCompensation インターフェースで補償トランザクションを登録している点です。 これにより、 authorizeBalance Activity が成功した後に authorizePoint Activity が失敗した場合は、 authorizeBalance を取り消す処理である cancelBalance という関数が補償トランザクションとして実行されます。 エラーハンドリング このワークフローエンジンでは、3種類のエラーを定義しています。 Completable Error : Workflow や Activity を失敗として完了させてよい、想定されたエラーです。例として、残高不足や利用制限があります。 Retryable Error: リトライ対象のエラーです。 Incompletable Error: Workflow を完了させずに停止し、Recovery Worker が後でリトライするエラーです。 Completable Error は、明示的に完了できるエラーだけを完了扱いにするための仕組みです。 クライアント側で ErrorMarshaler というインターフェースを実装したエラーとして定義される 該当しないエラーはすべて未完了として実行を停止し、Recovery Worker によってリトライされる 明示的に Completable Error を返さない限り Workflow は完了しない アプリケーションが意図していない異常な状態で Workflow が完了しない設計になる type ErrorMarshaler interface { MarshalCompletableError(error) ([]byte, error) UnmarshalCompletableError(marshaledErr []byte) error } 具体例として、ドメインのカスタムエラー型に Completable() というメソッドを定義し、それを使って ErrorMarshaler を実装します。 このようなカスタムエラー型を作っておくことで、ビジネスロジックで特定のエラーコードを含むエラーを返すと、ワークフローエンジンで完了可能なエラーとして処理されます。 type Error struct { code ErrorCode msg string } func (e *Error) Error() string { return e.msg } func (e *Error) Completable() bool { return e.code == ErrCodeCompletable } type workflowError struct { Code ErrorCode Msg string } type workflowErrorMarshaler struct{} func (workflowErrorMarshaler) MarshalCompletableError(err error) ([]byte, error) { var aerr *Error if !errors.As(err, &aerr) { return nil, err } if !aerr.Completable() { return nil, err } return json.Marshal(&workflowError{ Code: aerr.code, Msg: aerr.msg, }) } func (workflowErrorMarshaler) UnmarshalCompletableError(data []byte) error { var werr workflowError if err := json.Unmarshal(data, &werr); err != nil { return err } return &Error{ code: werr.Code, msg: werr.Msg, } } 活用事例 ここまで、独自に開発したワークフローエンジンの設計について紹介しました。 ここからは、決済以外のユースケースも含めて、社内での活用事例を3つ紹介します。 1. メルカリモバイル: 同期レスポンスと非同期処理の分離 例えば、メルカリモバイルの回線開通フローでは、Workflow と Child Workflow というサブのワークフローを定義し、同期レスポンスと非同期処理を分離しています。 具体的には、Workflow と Child Workflow で役割を分けています。Workflow は回線開通リクエストを DB に保存し、Child Workflow を fire-and-forget で起動してレスポンスを返します。 Child Workflow は、非同期で Pub/Sub イベントを発行します。失敗した場合は、Recovery Worker が Child Workflow を復旧します。 これにより、クライアントに即座にレスポンスを返しつつ、Pub/Sub 発行のような後続処理がバックグラウンドで実行されることを保証できます。 2. メルカリ グローバル EC 基盤: Saga によるチェックアウト管理 メルカリ グローバル EC 基盤では、Spanner ではなく PostgreSQL を採用しています。 ここでは、購買代行パートナーを経由して海外のお客さまが日本のメルカリの商品を購入する処理を例にします。 例えばチェックアウト確定フローでは、クーポン消費、注文作成、購買代行パートナーへの注文連携、注文確定通知送信の順に処理が進みます。 このチェックアウトの処理で、冒頭で紹介した暗号資産購入のユースケースと同様に Saga パターンを使ってトランザクションを管理しています。 途中で失敗した場合には、Saga による補償トランザクションでキャンセルします。 内製のワークフローエンジンを採用した理由には、社内にすでにある類似実装や運用基盤を活用したかったことがあります。また、メンテナーが社内にいるため直接サポートを受けられることや、必要な機能を柔軟に追加できて最適化しやすいことも大きな理由でした。 3. eKYC: Signal を使った long-running workflow eKYC によるお客さまの本人確認フローは、Workflow の中で数時間から数日の審査待ちが発生するという、いわゆる long-running workflow になっています。 これを実現するために、Temporal でも提供されている Signal という機能を実装しました。 Signal を使うことで、Workflow を中断し、外部から Workflow に情報を送って再開させるユースケースを実現できます。 長期フローを細切れのジョブとして分割せず、書類検証、審査待ち、承認または拒否という一連の流れを1本の Workflow として表現できます。 Signal を使ったアプリケーション側の実装イメージは次のようになります。 type ApprovalSignalParams struct { Approved bool RejectReason string } func (s *Service) approvalWorkflow(ctx context.Context, req *ApprovalRequest) (*ApprovalResult, error) { var result *ApprovalResult if err := s.wm.Activity(s.verifyDocument, req).ExecuteGet(ctx, &result); err != nil { return nil, err } var params ApprovalSignalParams if err := s.wm.Signal("approval").Receive(ctx, &params); err != nil { return nil, err } if !params.Approved { return nil, newCompletableError(params.RejectReason) } return result, nil } func (s *Service) handleApproval(ctx context.Context, workflowIdempotencyKey string, params ApprovalSignalParams) error { return s.wm.Signal("approval").Send(ctx, workflowIdempotencyKey, params) } approvalWorkflow という関数は、 verifyDocument という Activity を実行した後に、 approval という signal を待機します。 審査が終わり、外部から approval signal をこの Workflow に送信すると、 approvalWorkflow が途中から再開します。 まとめ 分散システムにおけるデータ整合性の課題に対して、メルカリでは Saga パターンによる結果整合性を採用し、それを支える仕組みとしてワークフローエンジンを内製しています。 この記事では、その背景と設計、社内での活用事例について紹介しました。 なお、この SDK を使った開発を支援するために、専用の静的解析ツールも開発して運用しています。このあたりの運用面についても発表で触れているので、興味のある方は Speaker Deck のスライドもぜひご覧ください。 次の記事は kubomiさんの「Build First, Discuss Later｜初回ミーティングに動くプロトタイプを持ち込んだら、意思決定が爆速になった」です。引き続きお楽しみください。

ファインディの森（ @jiskanulo ）と西村（ @sontixyou ）です。 2026年6月11日に開催されたAnthropic主催のイベント「Code w/ Claude: Extended | Tokyo」に終日参加してきました。 claude.com 本記事はその参加レポートです。私たちがセッションを聴いてどう感じたか、セッションの内容をどう活かすかの感想も書いていきます。 Workshopで気になったセッション How we Claude Code Ship your first Managed Agent ドメインエキスパートがソフトウェアを作る What happens when domain experts can finally build The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark まとめ ファインディでは一緒に働く仲間を募集しています Workshopで気になったセッション 西村は主にAnthropicメンバーによるWorkshopへ参加しました。Anthropicが取り入れている設定や仕組みを弊社のプロダクト開発フローに適用できるかを意識して聴きました。 How we Claude Code claude.com Anthropicメンバーが実際に使っているClaude Codeのセットアップ方法を紹介するものです。 今回のイベントでのワークショップで説明された題材は次のリポジトリで公開されています。 github.com このセッションで最も印象に残ったのは「徹底インタビュー」と「HTML先行プロトタイプ」の2つです。 「徹底インタビュー」では、Claude Codeにインタビュアー役を担わせて要件を引き出します。 インタビューでは、つぎのインタビュープロンプトをClaude Codeに渡して、HTMLのプロトタイプを作るための要件を引き出す設計になっていました。 I want to build a bill-splitting app, can you help me brainstorm with me on who the audience is, and then interview me in-depth using the AskUserQuestion tool about what to build, focusing on pulling out any ambiguities to create a spec. 上記のプロンプトを実行し、Claude Codeとのやりとりを通して、要件の曖昧さを潰していき、SPEC.mdを作成する流れが紹介されました。要件の曖昧さを上流で潰すことで、実装のやり直しを減らすという設計思想です。 つぎに「HTML先行プロトタイプ」ではSPEC.mdをもとに、4つの異なるデザインを提案させて、HTMLのプロトタイプを作る流れが紹介されました。 Read ../phase-1-planning for its spec file, then help me figure out the overall design of this app. Explore 4 different designs, and create a set of HTML files with important screens for each. 上記のプロンプトを実行すると、つぎのHTMLのプロトタイプが出力されました。 Markdown形式でデザイン仕様を書き出すのではなく、クリックできるHTMLのプロトタイプを出力することで、見た瞬間に判断できます。 設計するタイミングで、Claude Codeとの認識合わせが視覚的にできることで、実装フェーズでのやり直しが少なくなり、トークン使用量の削減につながります。 また、既に運用しているサービスではデザインシステムといったデザイン基盤があれば、精度よくHTMLを出力できる可能性があります。それによって、新しい機能のデザインをするときの認識合わせがスムーズになりそうだと思いました。 Ship your first Managed Agent claude.com Claude Managed Agents（CMA）の全体像を、インシデントレスポンスのデモを通して整理するワークショップです。 このセッションで印象に残ったスライドが「The brain left the box」でした。 以前のアーキテクチャは、Agent loopとTool executionが同じコンテナの中に同居していました。Managed AgentsではAnthropicが管理する1つのサービスとして動き、ツール実行のSandboxはツールが必要なときだけオンデマンドで起動します。クライアントが切断されていてもループは動き続けるため、ローカルのターミナルを閉じてもセッションが止まりません。 これまで西村の開発環境のClaude Codeの使い方では、ローカルPCでClaude Codeを稼働させているため、プロンプトを入力しないとAIエージェントが動き出せませんでした。また、並列セッション数も最大8が限界でした。 Managed Agentsはこの2点を変えられると感じました。オンデマンドで非同期で動き続ける実行環境があれば、人間の合図を待たずに実装する用途が一気に現実的になります。 試したい用途として思い浮かんだのは、着手できていないイシューの開発・リファクタリング、そして人間が介在せずにPRをマージすることです。 最後の「自律マージ」には前提条件を考えなくてはいけません。最低限必要な前提条件を決めておかなければなりません。 例えば、テストカバレッジが一定基準を超えていること、テストの堅牢性が担保されていることなどです。 これらの前提条件を満たすための仕組みを整えることが、AIエージェントによる自律マージの実現に向けた重要なステップになると感じました。 ドメインエキスパートがソフトウェアを作る 森はFounder stageを中心に話を聞いていました。 いずれのセッションもドメインエキスパートの知識・決定が重要であることを話されていました。 いくつかご紹介します。 What happens when domain experts can finally build claude.com 登壇はクイーンズランド大学のJason Tangen教授。AIネイティブ時代のプロダクトは、汎用的な人材ではなく深いドメイン知識を持つ個人から生まれるという主張です。 「去年までソフトウェアを一行も書いたことがなかった」という彼が、6ヶ月で3つの本番アプリをデプロイしました。 登場したアプリはいずれも学生向けのもので、シラバス生成ツール（classbuild.ai）、法廷証言トレーニング（crosscoach.ai）、学生向け説明ツール、学生の顔と名前を覚えるゲームなど。 専門家の頭の中に眠っていたアイデアが、AIにより作るコストが下がり具現化できるようになりました。 最後に聴衆へ「あなたが何年も密かに欲しいと思っていた小さなツールは何ですか？」「チームの中で、実際にその仕事をやり続けてきた人は誰ですか？」と問いかけられました。 コードを書く能力ではなく、「何を作るべきか」を知っていることが大切なのだと感じました。 The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark claude.com 登壇者はGahee Seo氏。分類の誤りが金銭的損失に直結する貿易コンプライアンス領域で、ドメイン知識とClaudeの組み合わせが基盤モデル単体を超える優位を生むことを示します。 韓国からEUへの輸送など、さまざまな規制が複雑に絡み合う貿易の領域では、どんなAIモデルを使うかよりも専門家の判断フローをどう再現するかが優位を決めるとのことです。 最初のプロトタイプはSingle agentで1件の分類に6分かかっており、また、アウトプット精度にも課題があったとのことです。 課題を解決するために分類器を新しく訓練するのではなく、専門家が5段階で判断するワークフローを複製したという設計思想を発表してくれました。 入力が曖昧なまま処理が走らないようinput gateを設けたこと 全規制ルールをsystem promptに詰め込む設計をやめ、必要な文書を検索する Retrieval と出力結果を検証する Verifierという構想に転換 これらの対応をとりあげていました。さらにエージェントを役割ごとに分割することで30秒まで短縮しました。 アウトプットではなくワークフローを教える、という発言もありました。 期待する出力形式を示すのではなく、専門家がどういう順番で何を見て判断するかをシステム化する。職人芸をインフラに変える、という表現が使われていました。 まとめ 西村が午前に参加したAnthropicのワークショップ2つには、共通した問いがありました。 How we Claude CodeのHTMLプロトタイプは、実装前に人間の判断を前の工程に集約する仕組みです。Ship your first Managed Agentの非同期実行は、後工程での人間の介在を手放すための基盤です。 方向は逆に見えますが、根底にある問いは同じだと感じました。「人間はどこで関与すべきか」を先に設計する、という考え方です。その2点を組み合わせることで初めて、AIと人間の役割分担がきちんと設計できると思いました。 森の参加したセッションは「個人開発者・アーリーステージな創設者向け」という性格のものが多かったです。個人が専門知識を武器にプロダクトを作る事例が多く、それ自体は示唆に富んでいました。 どのセッションでも専門家の知識、決定が大事であるという主張を別の角度から語っていました。 一方で、チームでどう使っていくか・チームの中でどう成長していくかという話はありませんでした。 最近個人的に悶々としている「専門家がいない領域でどう専門性を担保するか」「専門家をどう育てるか、時間をかけるしかないのか」という問いには答えが見つからなかったので引き続き考え続けます。 ファインディでは一緒に働く仲間を募集しています ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers