はじめに 生成 AI は、いまやあらゆる産業に新たな価値創出の機会をもたらす基盤技術になりつつあります。文章の作成や要約、コードの生成、問い合わせ対応、専門的な調査の補助など、これまで人手に頼っていた多くの業務を支援できるようになり、生産性向上とイノベーション創出のカギとして大きな期待が寄せられています。 その一方で、機密情報や個人情報を外部の生成 AI サービスに入力することへの懸念から、本格的な活用に踏み切れない企業も少なくありません。総務省の調査によれば、約 7 割の企業が AI 活用における「セキュリティリスク」を懸念しており、産業データの活用が十分に進んでいないことが課題として指摘されています（出典：総務省 「令和 6 年版 情報通信白書」 ）。つまり、生成 AI の可能性は広く認識されている一方で、「安心して自社のデータを預けられるのか」という信頼の問題が、活用の大きな壁になっています。 一般社団法人 AI データ主権共創機構（ CODAS : Co-creation Organization for Data Sovereignty & AI） はこの課題の解決策として日本発の「信頼できる AI」の構築を目指しています。 CODAS は「秘匿性を基盤とした産業特化型 AI 基盤の研究開発・実装・実証」に取り組む共創組織であり、企業・研究機関・行政が対等に参画しながら、日本の産業競争力の強化とデータ主権の確保を目的としています。AWS は、その研究開発を支える大規模言語モデル（LLM）の学習・推論基盤の構築をご支援しています。 この取り組みは、 国立研究開発法人 新エネルギー・産業技術総合開発機構（NEDO） の 「ポスト 5G 情報通信システム基盤強化研究開発事業／データの秘匿性を考慮した効率的な AI 学習手法の開発」 の一環として進められています。同事業では、生成 AI の性能向上を支えてきたウェブ上の公開データが学習し尽くされつつあるなか、今後の AI 開発においては企業や組織が保有する実データを安全に活用することが不可欠になる、という認識が背景にあります。しかし、実データの多くは個人情報や機密情報を含むため、データの秘匿性を考慮した学習手法の確立が重要な課題として掲げられています。 本ブログでは、 CODAS が目指す世界と、そのビジネス的な意義、そして、その実現に向けた第一歩として現在取り組まれている産業特化型 LLM の構築と、それを支える AWS 上の学習・推論基盤についてご紹介します。なお、本記事でご紹介するのは、 CODAS の活動のあくまで初期段階における取り組みのみです。 CODAS の構想はこの先、秘匿性技術の研究開発から社会実装、さらにはグローバルなエコシステム形成へと大きな広がりを見せていく予定であり、本記事はその出発点をお伝えするものとご理解いただければ幸いです。 CODAS が目指す、データ秘匿性を考慮した産業特化型大規模言語モデルの構築 なぜ「秘匿性」なのか 現在広く使われている汎用的な生成 AI は素晴らしい技術である一方、機密情報や個人情報の取り扱いという観点では、企業に大きな懸念を残しています。 CODAS は、この課題を大きく 3 つのリスクとして整理しています。 第一に、機密情報・データの流出リスクです。企業が外部の AI サービスに機密データを入力する場合、サービスの利用条件や設定に応じて、入力データの保存場所、保持期間、学習への利用有無などを十分に確認する必要があります。企業にとって、顧客データ、取引情報、技術情報といった競争力の源泉が、意図せず外部に流出するリスクは看過できません。 第二に、プライバシー侵害とデータ主権の喪失リスクです。学習データからの個人特定（メンバーシップ推論攻撃や学習データの再構成など）や、自社データが管理の及ばない環境で処理・保存されることへの懸念があります。加えて、各国でデータ保護規制が強化されるなか、データを国内で管理し、規制に準拠しながら活用することの重要性が高まっており、規制対応の負担も増しています。データがどこにあり、誰がアクセスでき、有事にも継続的に利用できるのかという「データ主権」は、経営レベルの論点になりつつあります。 第三に、こうした懸念が日本企業を AI 活用に踏み切れなくさせている、という現実です。 一般社団法人 日本情報システム・ユーザー協会（JUAS） の調査では、企業が AI 活用で懸念するリスクとして、データ漏洩リスク（70.3%）、AI の誤回答リスク（65.2%）、プライバシー侵害リスク（65.0%）、法令違反リスク（50.5%）が挙げられています（出典：JUAS 「企業 IT 動向調査 2025」 ）。懸念が先に立つことで、本来であれば大きな価値を生むはずのデータ活用が後回しになってしまう。この「もったいない」状況こそ、 CODAS が解こうとしている課題です。 CODAS は、この状況に対して「データは動かさない、モデルが動く」（Privacy-First AI）という発想の転換を掲げています。データを外部に送り出すのではなく、データが自社の管理下に留まったままで AI を活用できる世界を目指すものです。この発想は、単に情報漏洩を防ぐという守りの意味にとどまりません。これまで秘匿性への懸念から活用が進まなかった高価値なデータを、安心して AI に活かせるようにすることで、日本企業のデータ活用そのものを前に進める攻めの一手でもあります。守りと攻めを同時に成立させる。ここに、秘匿性を基盤とする AI のビジネス的な意義があります。 ロードマップと現在のフェーズ CODAS の最終目標は、データ漏洩防止、プライバシー侵害耐性、データ主権の確保といった秘匿性を担保しながら、産業の実務に耐えうる高性能な AI を実現することです。差分プライバシーや秘密計算などの秘匿性技術と、産業に特化したモデルを組み合わせることで、汎用モデルにはない「信頼性」と「専門性」の両立を目指しています。秘匿性を高めるほど性能とのトレードオフが生じやすいため、この両立には継続的な研究開発と強固な計算基盤が欠かせません。 秘匿性技術は、適用先となる高性能なベースモデルがあって初めて実証・評価できます。そのため CODAS は、まず秘匿性研究の土台となる産業特化型大規模言語モデルを構築し、その上で秘匿性技術の研究開発を積み上げるアプローチを取っています。 このベースモデルは領域特化の高度な処理を担い、各企業のユースケースに特化した個社モデルと連携する 2 層構造を想定しています。特に、情報漏洩リスクへの懸念から慎重な判断が求められる金融・保険領域を最優先の実装領域と位置づけ、社会実装の標準を確立することを目指しています。また、特定のモデルに依存しない開発手法を採用し、今後さらに高性能なモデルが登場しても柔軟に取り入れられるようにしています。 CODAS では、大学や専門企業が秘匿性技術に関する複数の研究テーマを分担しています。ベースとなる LLM の開発は ABEJA 様が担い、AWS は大規模なモデル学習を支える計算基盤の構築を支援しています。各研究テーマ、ベースモデル、計算基盤を組み合わせる体制が、 CODAS の挑戦を支えています。 産業特化型大規模言語モデルの学習と評価に関する取り組み 産業特化型大規模言語モデル開発の第一段階として、 CODAS では、パブリックデータをベースとした大規模コーパスの構築、教師付きファインチューニング用データセットの合成、継続的事前学習と事後学習（教師付きファインチューニングおよび強化学習）、学習済みモデルの評価に取り組んでいます。本節では、こうした学習・評価の考え方と主な検証内容を紹介します。 (1) 学習済みモデルの評価 モデルの性能は、日本語・英語それぞれにおける汎用的な能力と、金融分野に特化したタスクを遂行する能力の両面から評価します。このため、複数のパブリックデータセットを選定し、必要に応じて対象タスクに合わせた改修を行いました。 評価には、正解との一致を確認する機械採点に加え、自由記述など単純な正誤判定が難しいタスクに対応するため、LLM-as-a-Judge を用いています。これにより、モデルが金融領域の知識を獲得しているかだけでなく、汎用的な言語能力を維持できているかを継続的に確認します。 図 1: JLM-Fin-Eval と EDINET-Bench を用いた、汎用能力と金融分野の能力を評価するベンチマークの例 (2) 大規模コーパスの作成と事前学習 継続的事前学習に向けて、対象領域の知識を取り込むための大規模コーパスを準備しています。コーパスの品質や構成は、その後のモデル性能に大きく影響するため、データの収集・整形・選別を行ったうえで学習に用います。 また、学習の実施を通じて、データ構成や学習条件がモデルの汎用能力および金融関連タスクの性能に与える影響を検証しています。 (3) 学習用データセットの合成と教師付きファインチューニング 事後学習では、教師付きファインチューニング（Supervised Fine-Tuning、SFT）に用いる学習データセットを、生成 AI モデルを活用して合成しています。金融関連タスクの性能を高めながら汎用的な能力も維持・向上させるため、金融特化型データセットと汎用データセットを組み合わせます。 検証では、学習対象モデルの系統を考慮し、SFT 用データの生成に用いるモデルの違いが、SFT 後の性能に与える影響を分析しています。あわせて、金融特化型データと汎用データの配合を変え、汎用能力と金融関連タスクの遂行能力をバランス良く最適化する方法を検討しています。 図 2: 合成データ生成モデルの系統差が SFT 後の性能に与える影響を検証する考え方 (4) 強化学習による論理的能力の強化と指示追従能力の回復 SFT に加えて、論理的能力の向上を目的とした強化学習（Reinforcement Learning、RL）にも取り組んでいます。強化学習では数理的能力の向上に加え、SFT 後に生じ得る指示追従能力の低下、特に指示に含まれる出力制約を守る能力の低下を改善することを目指します。 評価の結果、SFT 後に実施する強化学習が、こうした指示追従能力の回復に寄与することを確認しました。モデルの能力を単一の指標で評価するのではなく、論理性、指示追従性、専門領域のタスク性能を総合的に捉えながら、学習方法を改善しています。 図 3: SFT 後に低下した指示追従能力と、RL による性能回復の評価結果 データセットの構成、実験条件、評価方法、詳細な結果については、今後 ABEJA 様の技術ブログ にて公開予定です。 合成データの作成、産業特化型大規模言語モデルの学習、および、学習済みモデルの評価を実行するためには、GPU を含む大規模計算機リソースが必要となります。また、多くの GPU を用いて効率的に分散学習を行うには、ストレージ・ネットワーク通信の観点でも検討すべき事項があります。さらに、安全に開発を進めるうえでは権限周りの管理・運用も不可欠です。 CODAS では、産業特化型大規模言語モデル構築のための学習・推論基盤として、72 台の p5en.48xlarge EC2 インスタンスをコンピュートノードとして利用する、 AWS ParallelCluster を用いた大規模 GPU クラスターを AWS 上に構築しています。次章では、AWS 上でのモデル学習・推論基盤の構築について紹介します。 AWS 上で実現する大規模言語モデル学習・推論基盤 大規模学習基盤の設計方針 大規模言語モデルの学習・推論基盤を構築するには、GPU の計算性能だけでなく、ノード間通信、共有ストレージ、ジョブ管理、監視を一体として設計する必要があります。そのために CODAS が初期構築の出発点としたのが、AWS Labs のオープンソースである awsome-distributed-ai （旧称 awsome-distributed-training）です。同リポジトリでは、大規模モデル学習向けのリファレンスアーキテクチャ、学習用サンプル、検証・オブザーバビリティ用ツールをまとめたものをオープンソースで提供しています。 学習・推論基盤の実装時には、awsome-distributed-ai リポジトリに含まれるリファレンスアーキテクチャを VPC、共有ストレージ、Elastic Fabric Adapter（EFA）、Slurm といった分散学習基盤の主要な構成要素を構築するための出発点としました。これにより、一からすべて自分たちで組み立てるのではなく、複数のチームで GPU クラスターを共同利用する際のロールや権限、接続方法、安定運用のための設計を含む、独自の要件に関する議論と実装に注力しやすくなりました。リファレンスアーキテクチャはあくまで汎用的なものです。そのため、そのまま採用するのではなく、実際の用途と運用体制に合わせて、不要な要素の削除や、安全性向上などを目的として必要な仕組みを追加実装することが重要です。 学習・推論基盤の全体像 クラスターの構築と管理には AWS ParallelCluster を利用し、ジョブスケジューラーとして Slurm を採用しています。ヘッドノードは Slurm のスケジューリングとクラスター制御を担っています。ユーザーは別途立ち上げたログインノード上で通常のコーディング作業やジョブ投入、コンテナの準備などを実施することが可能です。学習ジョブは EFA を備えた GPU コンピュートノード上で実行し、Enroot と Pyxis を組み合わせて、Slurm からコンテナ化した学習環境を起動しています。現在は NVIDIA H200 を 8 基搭載した p5en.48xlarge GPU インスタンス 72 台をワーカーノードとする規模までスケールしています。 ストレージは役割に応じて使い分けを行っており、学習データやチェックポイントを扱うための高性能な共有領域には Amazon FSx for Lustre 、ホーム領域には Amazon FSx for OpenZFS を採用しています。また、 Amazon S3 と FSx for Lustre は Data Repository Association（DRA） で連携しています。主要コンポーネントとデータの流れを 図 4 のアーキテクチャ図に示します。 図 4: AWS ParallelCluster と Amazon EC2 GPU インスタンスを用いて構築した大規模言語モデル用学習・推論基盤のアーキテクチャ図 組織独自の要件を仕組みに落とし込む 大規模 GPU クラスターを複数のチームで継続的に利用するには、GPU やネットワークの性能だけでなく、誰が、どのように、安全に利用できるかをあらかじめ設計しておくことが重要です。そこで、本環境ではクラスターへのユーザーアクセスを AWS Systems Manager Session Manager に一本化し、SSH キーペアを前提としない構成を採用しています。さらに、SSH キーペアが設定された場合にはクラスターのデプロイを失敗させることで、意図せずアクセス方針から逸脱した構成になることを防ぎます。IAM 権限についても、構築・運用に必要な権限を整理し、最小権限の原則に沿って設定しています。 ノードごとに役割を明確に分離している点も、この基盤の特徴です。ヘッドノードは Slurm のスケジューリングとクラスター制御に専念させ、日常的なコーディング、コンテナの準備、ジョブ投入はログインノードで行います。これにより、ユーザーの作業がクラスター制御に影響することを抑え、安定した運用につなげます。複数のチームが利用する環境では、チームごとにログインノードのプールを用意しつつ、全ノードのユーザー ID（UID）とグループ ID（GID）を統一的に管理します。共有ファイルシステム上の所有権と Slurm が認識する利用者を整合させることで、チームをまたぐデータセットやモデルの共同利用も可能にしています。 また、コンテナのビルドは一時的に大きなディスク負荷を発生させるため、ログインノードのルートボリュームに負荷が集中しない設計としています。ルート EBS ボリュームの容量を確保するとともに、成果物は FSx の共有ストレージに配置します。ローカル NVMe を利用する処理については、Slurm デーモンの起動前に NVMe の準備とマウント元の検証を完了させます。想定したストレージを利用できない場合には処理を停止することで、不完全な状態でノードが起動することを防ぎます。 異常の早期顕在化と計測に基づく運用 大規模分散学習では、単一ノードの異常やストレージ容量の不足、ネットワーク通信の不調が、学習ジョブ全体の性能や成否に影響します。そのため、 Amazon CloudWatch 、 Amazon Simple Notification Service（Amazon SNS） 、 AWS Lambda 、Slack を組み合わせ、FSx for Lustre の容量しきい値超過や GPU の故障を自動的に通知する仕組みを設けています。クラスターの利用者と管理者は必要な状況を速やかに把握し、ストレージの拡張やノードの切り離しといった対応を判断できます。 ノード間通信では、コンピュートノードの構成時に EFA デバイスの存在だけでなく、EFA プロバイダーを実際に利用できることまで確認します。検証に失敗した場合は、診断に必要なログを残してデプロイを停止します。こうした事前検証により、ジョブは実行できても通信性能が十分に出ないという発見しにくい問題を、学習開始前に検出できます。 ストレージについても、推測ではなく実測したメトリクスに基づいてボトルネックを切り分け、必要に応じて容量をスケールさせる運用としています。ノード障害、通信、ストレージのいずれも例外として扱うのではなく、発生を前提に検知・判断・対応できるようにしておくことが、大規模 GPU クラスターの継続的な利用には不可欠です。 ここまで紹介した工夫に共通するのは、運用上のルールや障害時の対応を手順書にとどめず、クラスターのデプロイや起動の過程で自動的に確認できる仕組みとして実装している点です。リファレンスアーキテクチャを出発点にしながら、組織の利用形態や実運用で得られる知見を構成へ反映し続けることで、複数チームが大規模言語モデルの学習・推論基盤を安定して共同利用できる環境を目指しています。 おわりに 本ブログでは CODAS によるデータの秘匿性を考慮した AI 学習手法の開発に関する大規模言語モデル学習・推論基盤の構築に向けた取り組みについて紹介しました。上述の通り、本ブログで紹介した内容は CODAS による初期段階の取り組みの一部に関するもののみであり、 CODAS の活動は今後さらに大きく広がりを見せていく予定です。AWS では CODAS 担当アカウントチーム、コンピュート・生成 AI スペシャリストチーム、生成 AI イノベーションセンターなど、複数のチームが一丸となって、 CODAS の本活動に対する支援を行っています。 著者プロフィール 原田 伴誉 (Tomotaka Harada) 株式会社ABEJA エンタープライズプラットフォーム開発本部／データサイエンス部所属。京都大学大学院修了後、金属メーカーでプラントエンジニアリングとDX推進に従事し、設備自動化や画像処理を活用した検査自動化、データ活用を推進。在職中にボストン大学でApplied Data Analyticsを修了し、米国企業で画像AI開発も経験。ABEJAではRAG、レコメンドシステム、スポーツ動作解析、直近はLLM開発に参画し、製造現場の理解とAI開発力を併せ持つエンジニアとしてプロジェクトを推進している。 久米 拓馬 (Takuma Kume) 株式会社ABEJA 経営企画統括部 情報システム・セキュリティグループ所属。AWSでのインフラ構築を専業とするSierに8年所属。インフラの構築から運用や設計提案を経験し、新規立ち上げからマイグレーションなど幅広く対応。ABEJAでは情報システム部門の運用をメインとし、前職での知見を活かして単体プロジェクトのインフラ構築支援を実施。 長谷川 潤 (Jun Hasegawa) CODAS の最高プロジェクト責任者であり、創業者／リサーチャーです。連続起業家として、Omise（決済事業）と OMG Network（ブロックチェーン事業）を創業し、いずれもユニコーン企業へ成長させました。これまでに累計 5 億ドル以上を調達し、現在は決済・ブロックチェーン・プライバシー AI の 3 領域でグローバル事業を率いています。 中越 洋(Hiroshi Nakagoe) CODAS の Technical Head および Archetype Digital の VPoE として、プライバシー保護技術に関する 7 件の研究プロジェクト、1 つの統合型生成 AI プラットフォーム、プライバシー保護 AI システムを評価する複数の PoC など、研究開発と社会実装プロジェクトをリードしています。テクノロジー業界で 20 年以上の経験を持ち、ML/AI サービス、データ分析プラットフォーム、IoT サービス、エンタープライズストレージ、エンタープライズ向け運用ツール、LSI の研究開発を通じて、専門知識を実社会の課題解決に応用してきました。東京を拠点に活動しています。 黒澤 蓮 (Ren Kurosawa) AWS Startup Frontier AI ソリューションアーキテクトで、Startup 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。 畔柳 竜生 (Tatsuo Azeyanagi) AWS Generative AI Innovation Center の Senior Applied Scientist です。生成 AI や機械学習サービスを活用し、顧客の課題解決に取り組んでいます。AWS に入社する前は、日本、アメリカ、フランス、ベルギーの大学・研究機関にて、素粒子論の研究をしていました。 松浦 大輝 AWS Startup, Frontier AI Team の Account Manager です。生成 AI の基盤モデル開発企業からフィジカル AI スタートアップまで、日本の最先端 AI 企業のクラウド活用と事業成長をご支援しています。GPU クラスターを活用した大規模学習基盤の構築支援や、業界横断のコミュニティ形成にも取り組んでいます。

Cloudflare Walletsが使う決済プロトコル x402 を理解する 目次 はじめに x402が対象とする課題 プロトコルフロー ② 402 Payment Required と PaymentRequirements scheme が取る値 — exact と upto ③ authorization への署名 ④ PaymentPayload の送信 ⑤ verify / settle と facilitator 決済の確定と不可逆性 HTTPを利用する構成のメリット 支払ってよいかの判断は仕様の範囲外 まとめ 参考 はじめに こんにちは、開発本部開発1部の 赤川 です。食事管理アプリ ヘルシカ の開発をしています。 ダイエット・食事管理・体重管理・カロリー計算 - ヘルシカ every, Inc. ヘルスケア／フィットネス 無料 2026年8月4日、Cloudflareが Cloudflare Wallets を発表しました。これは、Web上でサービスの購入や入金を行うためのウォレットで、Cloudflareのアカウントに紐づきます。現時点ではウォレットの識別子の予約のみが提供されており、僕もとりあえず予約してみました。 Cloudflare Wallet Tagを予約した Cloudflare Walletsでは、アカウントが持つWalletから、エージェントが使うVirtual Walletに支出権限を委任できます。エージェントはVirtual Walletを使って、API、MCPツール、コンテンツなどを購入できます。 この購入のやり取りには、 x402 という決済プロトコルが使われています。x402は、HTTPのリクエストとレスポンスの中だけで完結し、支払いが必要であることを示すのに、HTTPステータスコードの 402 Payment Required 1 を使っています。 本記事ではこの x402 について、ドキュメントをあたりながらまとめてみました。 x402が対象とする課題 例えば有料APIを利用しようと思ったら、我々は一般に次の手順を踏みます。 サービスにサインアップする クレジットカードなどの決済手段を登録する APIキーを発行する そのキーをリクエストに付けて呼ぶ 月末にまとめて請求される 認証と課金がフローとして完全に分離しており、いずれも事前のサインアップを前提としています。 人間が利用する分には何の問題もないですが、クライアントがAIエージェントである場合、この前提が制約になります。手順1〜3のうち、サインアップページは人間向けのUIとして作られており、決済手段の登録も人間の承認が必要です。エージェントは事前登録された識別子も支払い手段も持たないため、この3手順の実行には人間の介在が必要になります。 x402は、事前の登録手続きなしに支払いを成立させる方式を定義しています。 プロトコルフロー プロトコルのフローは次のとおりです。この章の図や記述は、 x402 Specification v2 と Cloudflare の x402 ドキュメント に基づいており、執筆時点で最新のv2について書いています。 x402のプロトコルフロー このフローには、アカウントやセッション、事前に共有したAPIキーなどは含まれません。ClientとServerはこのリクエストで初めて通信し、支払いが成立します。 ※ 実際の支払いは、ブロックチェーン上でトークンを送ることで成立します。USDCなどのステーブルコイン（米ドルなどの法定通貨に価値を連動させたトークン）が使われます。 ② 402 Payment Required と PaymentRequirements ①のリクエストに対して、Serverは②で 402 Payment Required を返します。支払いの条件は PAYMENT-REQUIRED ヘッダに、Base64エンコードされたJSONとして載ります。 このJSONの accepts フィールドに、支払いの条件が配列で入ります。要素1つが「この条件で払ってくれれば、このリソースを渡すよ」という1件分の提示にあたり、これを PaymentRequirements と呼びます。配列なのでServerは条件の異なる複数の選択肢を並べられ、Clientはその中から1つを選びます。 PaymentRequirements は次のフィールドから構成されます。 フィールド 内容 scheme 支払いスキーム（ exact / upto ） network 対象ブロックチェーン（Base、Ethereum、Solana など） amount 金額 asset トークン種別（USDC など） payTo 支払いの宛先アドレス maxTimeoutSeconds タイムアウト scheme が取る値 — exact と upto scheme フィールドは支払い方式を指定します。 Cloudflare のドキュメント に記載されているのは次の2つです。 exact : 固定額の送金です。EVM（Ethereum Virtual Machine） 2 上では USDC を payTo のアドレスに送金します。②の時点で金額が確定しているケースに対応します。 upto : 上限額を先に承認し、実際の課金額を決済時に確定します。LLMの推論APIのように、実行するまでトークン数が確定せず、金額が事後に決まるケースに対応します。 ③ authorization への署名 Clientは、 accepts の中から採用する PaymentRequirements を1つ選び、その内容を authorization オブジェクトに反映して署名します。authorization の形は、 scheme とチェーンの種類の組み合わせで決まり、EVM上で exact を使う場合は次のフィールドを持ちます。 フィールド 内容 from 送金元アドレス to 宛先アドレス value 金額 validAfter / validBefore 有効期間 nonce 一度きりの値 署名は自身の秘密鍵で行います。署名が保証するのは、その鍵の保有者にしか生成できないこと、署名対象が1バイトでも変われば検証に失敗すること、の2点です。 nonce は一度きりの値であり、 validBefore で有効期間が区切られるため、同じ署名を他の支払いに再利用することはできません。 ④ PaymentPayload の送信 署名と authorization は PaymentPayload にまとめられ、 PAYMENT-SIGNATURE ヘッダに載って、同じURLに再送されます。 PaymentPayload は次の構造です。 { " x402Version ": 2 , " resource ": { ... } , " accepted ": { /* ②の accepts から選んだ PaymentRequirements */ } , " payload ": { " signature ": " ... ", " authorization ": { " from ": " ... ", " to ": " ... ", " value ": " ... ", " nonce ": " ... " } } } ⑤ verify / settle と facilitator ⑤でServerが行う検証と決済は、facilitator に委譲できます。facilitator は、支払いの検証とブロックチェーンへの送信を担うサービスで、次の2つのエンドポイントを提供します。 POST /verify : 支払いペイロードが有効かを、ブロックチェーン上で送金を実行せずに検証する POST /settle : 検証済みの支払いをブロックチェーンに送信し、送金を確定させる facilitator の利用は必須ではありませんが、ブロックチェーンとのやり取りを抽象化できるため、Cloudflareのドキュメントでは推奨されています。 Clientは facilitator と直接通信せず、ServerとHTTPで通信します。⑤の内側を展開すると、次のようになります。 facilitator を含む⑤の内側 決済が確定すると、Serverは⑥でリソースを返します。決済の確認は PAYMENT-RESPONSE ヘッダに載ります。 決済の確定と不可逆性 x402の決済は、1回の送金で確定します。カード決済のように、支払いを承認する段階と実際に資金が動く段階が分かれることはありません。これにより、リソース1件ごとのような少額の支払いでも短時間で決済できますが、同時に次の制約が生じます。 決済を取り消せない プロトコルとして返金手段を定義していない 誤送金や詐取による送金があった場合、プロトコルの範囲では資金は戻りません。返金や救済を実装する場合は、アプリケーション層で別途定義することになります。 HTTPを利用する構成のメリット x402は決済専用のプロトコルを新設せず、支払いのやり取りをHTTPのリクエスト/レスポンスサイクルの中で表現します。そのためクライアントを選びません。エージェント、curl、サーバ間通信のいずれも対象になり、SDKも必須ではありません。 402応答は特定のURLに対する支払い要求なので、値付けの単位もURLになります。エンドポイントごと、MCPツールごとに価格を返せます。 支払ってよいかの判断は仕様の範囲外 x402の仕様が定義しているのは、3つのHTTPヘッダ、 PaymentRequirements と PaymentPayload の構造、facilitator の verify / settle の手順、および scheme です。「どのような条件で支払いを承認するか」は定義されていません。仕様上、正しく署名されたペイロードは正当な支払いとして処理されます。 Cloudflare Walletsは、この判断をウォレット側で縛る仕組みを持っています。エージェントに渡すVirtual Walletには、使ってよい金額の枠（allowance）、支払い先の許可リスト（allow list）、1回あたりの上限額（maximum transaction size）を設定できます。 これらはウォレット側の設定なので、エージェントが何をしようとしても、枠を超える送金や、許可リストにない相手への送金は成立しません。x402が定義していない「支払ってよいか」の判断を、エージェント任せにせず、ウォレットの設定として持たせている構成です。 まとめ x402の仕様を整理すると、次のようになります。 決済専用のプロトコルを新設せず、HTTPのリクエスト/レスポンスサイクルで支払いを表現する 事前のアカウントもAPIキーも使わず、402応答とその再送だけで支払いが成立する scheme として exact （固定額）と upto （上限額の事前承認）を定義する 検証と決済は facilitator に委譲できる。利用は必須ではない 決済はブロックチェーン上で確定し、プロトコルとして取り消し手段を持たない 支払ってよいかの判断は仕様の範囲外で、クライアント側に委ねられる 最後までお読みいただきありがとうございました。 参考 Announcing Cloudflare Wallets: The programmable wallet for the agentic Internet - The Cloudflare Blog （2026年8月4日） x402 - Cloudflare Agents docs x402 Specification v2 - coinbase/x402 RFC 9110: HTTP Semantics - 15.5.3. 402 Payment Required 現行のHTTP仕様である RFC 9110 では "The 402 (Payment Required) status code is reserved for future use." と記述されています。402が標準として用途を定義されてこなかったことを、僕は今回の記事を書くまで知りませんでした。 ↩ Ethereum が採用しているブロックチェーンの実行環境です。これを採用するチェーンは多く、Cloudflareのドキュメントも EVM に対応するチェーンとして Base、Ethereum、Polygon などを挙げています。 ↩

暗号資産取引所におけるテスト案件について、「一般的なウェブサービスのテストと何が違うのか」「金融や暗号資産の知識がなくても対応できるのか」と不安を感じるケースは少なくありません。 暗号資産取引所では、画面や機能が仕様どおり動くだけでなく、 顧客の資産や取引データが正確かつ安全に処理されること が非常に重要です。 国内の暗号資産交換業者には登録制度が設けられており、利用者保護の観点からシステム管理や分別管理などが求められています。 さらに近年は、署名鍵の管理だけではなく、外部委託先を経由した攻撃なども踏まえ、暗号資産交換業者には幅広いサイバーセキュリティ対策が求められるようになっています。 一方で、テストケース作成、不具合報告、仕様確認といった一般的な品質保証の経験を活かせる部分も多く、最初から暗号資産の専門家である必要はありません。 実際の暗号資産取引サービスの品質保証では、開発の最終段階でテストするだけではなく、要件定義など上流工程から品質を作り込む考え方も採用されています。 そこで今回は、 暗号資産取引所のテストで確認する内容と必要なスキルを、実務の流れに沿って整理しました！ 仕事内容を具体的に把握することで、現在の経験をどこまで活かせるのか、不足している知識を何から補えばよいのか判断しやすくなります。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 暗号資産取引所のテストとは？普通のウェブテストとの違いをつかもう！ 暗号資産取引所もウェブサービスの一種であるため、画面表示、入力チェック、データ更新、不具合確認といった基本的なテストの考え方は一般的なシステムと共通しています。 大きく異なるのは、 不具合が金銭や暗号資産の移動、顧客資産、本人確認などに直接影響する可能性があること です。 国内の暗号資産交換サービスは利用者の財産を扱う金融サービスであり、システム管理やセキュリティは利用者保護と密接に関係しています。 そのため、暗号資産取引所のテストでは「ボタンを押したら正しい画面へ移動した」という確認だけでは十分とはいえません。 注文から約定、残高更新、入出金、外部サービスとの通信までをつなげて確認し、 取引全体として正しい結果になっているか を評価する視点が必要です。 この特徴を理解すると、一般的なウェブテストの経験を活かせる部分と、金融・暗号資産領域で新たに学ぶべき部分を切り分けやすくなります。 正しく動くだけでなくお金と暗号資産が正しく動くことを確認する！ 暗号資産取引所には、口座開設、本人確認、ログイン、日本円の入出金、暗号資産の売買、暗号資産の入出庫、取引履歴など多くの機能があります。 テストでは、それぞれの画面が動作することに加えて、 取引の前後で残高や注文状態、手数料、取引履歴が矛盾なく変化しているか を確認する必要があります。 たとえば暗号資産を購入した際、注文完了の画面だけが正しく表示されても、日本円残高や暗号資産残高が間違っていればサービスとしては重大な不具合です。 注文が成立しなかった場合には、資産が誤って減っていないか、失敗した処理が取引履歴へ残っていないかといった確認も欠かせません。 暗号資産交換業では顧客資産の安全な管理が重要な前提となっており、システム品質と資産管理を切り離して考えることはできません。 そのため暗号資産取引所のテストでは、 画面単位ではなく、利用者が取引を始めて資産や履歴へ反映されるまでを一つの流れとして見ること が基本になります。 なぜ暗号資産取引所では通常のシステム以上に品質が重視される？ 一般的なウェブサービスでも障害は問題になりますが、暗号資産取引所では障害によって利用者が取引できなくなったり、資産の管理へ影響したりする可能性があります。 さらに、暗号資産の移転には秘密鍵や署名に関わる仕組みが存在するため、通常のウェブサービスとは異なるセキュリティ上のリスクも考慮しなければなりません。 国内では過去の暗号資産流出事案を受けて、署名鍵の管理だけでなく、金融機関と同水準の幅広いサイバーセキュリティ態勢を整える方向で対策が強化されています。 また、金融サービスは不正利用やマネー・ローンダリングへの対策も重要であり、暗号資産交換業者も対策が求められる金融機関の範囲に含まれています。 品質保証の役割も、完成した機能からバグを探すだけに限定されません。 実際の暗号資産取引サービスでも、要件定義などの上流工程から品質保証担当者が参加し、仕様の矛盾や不足を早い段階で発見する取り組みが進められています。 何を確認する？暗号資産取引所で外せないテスト観点を押さえよう！ 暗号資産取引所のテストでは、単純な正常系テストだけではなく、 取引が失敗した場合や通信が途切れた場合まで含めて結果の整合性を確認すること が重要です。 対象になるのは画面だけではなく、API（Application Programming Interface：システム同士をつなぐ仕組み）、データベース、認証、外部サービスなど多岐にわたります。 特に暗号資産取引では、一つの処理の途中で複数のシステムが関係するケースもあるため、個別機能が正常でも全体の結果が正しいとは限りません。 そのため、テスト設計では「機能が動いたか」から一歩踏み込み、 資産・データ・権限・通信・性能という複数の観点を組み合わせること がポイントです。 最初からすべてを専門的に理解する必要はなく、利用者が行う一連の取引を起点に整理するとテスト観点をつかみやすくなります。 機能テストでは金融取引の一連の流れを確認する！ 機能テストでは、口座開設からログイン、入出金、売買注文、取引履歴まで、利用者が実際に操作する流れをもとに確認していきます。 正常に注文できるケースだけでなく、残高不足、注文数量の上限・下限、無効な入力値、認証切れなどの 異常系や境界値 も重要なテスト対象です。 たとえば注文時に通信エラーが発生した場合、画面上では失敗しているのに裏側では注文だけ成立してしまうと、利用者が再操作して二重注文につながる可能性があります。 そのため、エラー表示だけではなく、注文状態、残高、履歴、データベースなどを合わせて確認し、処理途中の状態が残っていないかを確かめます。 本人確認や不自然な取引への対応なども金融サービスの重要な業務であるため、単純な売買機能だけを見ればよいわけではありません。 操作開始から最終的な資産・履歴の反映までを一つのシナリオとして設計すること が、暗号資産取引所の機能テストでは大切です。 外部連携テストでは相手側が正常とは限らないと考える！ 暗号資産取引所では、自社システムだけですべての処理が完結するとは限らず、本人確認、銀行、認証など外部サービスとAPIで連携するケースがあります。 APIはソフトウェア同士が通信するための仕組みであり、画面から見えない場所で多くのデータがやり取りされています。 テストでは正常な応答だけでなく、 タイムアウト、通信エラー、想定外のデータ、同じリクエストの再送 といったケースまで考える必要があります。 外部サービスが一時的に利用できない場合でも、自社側で不正な状態が残ったり、同じ処理が二重に実行されたりしないことを確認します。 またAPIには、認証不備や権限確認の不足によって、本来アクセスできない情報や機能へ到達できてしまう代表的なセキュリティリスクがあります。 そのため外部連携テストでは、 通信が成功したかだけではなく、その利用者に許可された処理なのか、失敗後の状態まで安全なのか を確認する視点が欠かせません。 お金のズレを防ぐ！データ整合性と同時実行のテストを重視する 暗号資産取引所では、取引前後の日本円残高、暗号資産残高、注文数量、手数料、履歴などがすべて矛盾なく一致している必要があります。 特に注意したいのが、複数の処理がほぼ同時に実行される場面です。 同じ資産を使った注文が短時間に複数送信された場合や、処理完了前に再操作された場合でも、 保有している以上の資産を使用できたり二重に残高が減ったりしないこと を確認します。 また、処理途中でサーバーやネットワークに問題が発生したケースでは、一部のデータだけ更新される状態を防げているかも重要です。 画面上の表示だけでは判断できない場合には、SQL（Structured Query Language：データベースを操作・確認するための言語）を使って内部データを確認したり、ログから処理順序を追ったりします。 金銭や暗号資産を扱うシステムでは、 一つ一つの画面よりも最終的に資産の帳尻が合っているかという視点 が重要になります。 安心して使えるようセキュリティと性能と記録まで確認する！ 暗号資産取引所では、利用者本人だけが資産に関する操作を行えるよう、ログインや権限管理を正しく機能させる必要があります。 認証については、パスワードだけでなく複数の要素を利用する仕組みなど、リスクに応じて強度を高める考え方があります。 APIでも、他人のデータへアクセスできる権限不備や、認証処理の弱点は代表的なセキュリティリスクとして整理されています。 そのためテストでは、一般利用者が管理機能へアクセスできないか、別ユーザーの情報を参照できないか、認証情報が無効になった後も操作できてしまわないかなどを確認します。 さらに価格変動が大きい時間帯などにアクセスや注文が集中しても、処理が極端に遅くなったり停止したりしないことを負荷テストで確認する視点も必要です。 2026年には暗号資産交換業者を対象として攻撃者の視点から侵入を試みる 脅威ベースのペネトレーションテスト を進める方針も示されており、サイバー攻撃を前提とした検証の重要性は高まっています。 暗号資産取引所のテストで求められるスキルは？今の経験を確認しよう！ 暗号資産取引所のテストと聞くと、ブロックチェーンや金融の高度な専門知識が最初から必要だと考えがちですが、実務の土台になるのは一般的な品質保証のスキルです。 仕様を読み取り、テスト観点を整理し、正常系と異常系のケースを作り、不具合を再現できる形で報告する能力は暗号資産分野でも活用できます。 そのうえで、SQLやAPI、ログ調査などの技術スキルと、担当する金融サービスの業務知識を追加すると確認できる範囲が広がります。 暗号資産取引サービスの品質保証組織でも、単なるテスト実行だけでなく、上流工程から仕様を確認して品質を作り込む役割へ領域が広がっています。 そのため、 現在のテスト経験を捨てて一から学び直すのではなく、既存スキルの上に金融・暗号資産の知識を積み上げる と考えると取り組みやすくなります。 ウェブやアプリのテスト経験はそのまま活かせる！ 一般的なウェブシステムで経験するテストケースの作成、テスト実施、不具合報告、修正後の再確認などは、暗号資産取引所でも基本となるスキルです。 仕様から条件を整理し、正常な操作だけではなく、入力ミス、境界値、エラー、権限違いなどを洗い出すテスト設計力もそのまま応用できます。 特に暗号資産取引所では複数の処理がつながるため、不具合が見つかった場所だけではなく、 どの操作からどの状態を経由して問題が発生したのかを整理して伝える能力 が役立ちます。 開発者や企画担当者と仕様を確認し、「この場合の正しい結果は何か」をすり合わせるコミュニケーション力も重要です。 暗号資産取引サービスの品質保証では、完成後のテストだけではなく要件定義から参加し、仕様の矛盾を早期に発見する取り組みも行われています。 金融経験がなくても、 テストの基本を身につけていること自体が大きな土台になる と考えられます。 データベースと外部連携とログを扱えると対応範囲が広がる！ 画面操作だけでは、暗号資産取引所の内部でデータが正しく処理されたか確認しきれない場面があります。 SQLを扱えると、注文状態、残高、履歴などのデータを確認できるため、画面表示と内部データが一致しているか検証しやすくなります。 APIの仕組みを理解すると、外部サービスとの通信内容やバックエンド側の処理を直接確認でき、画面だけを対象にしたテストよりも対応範囲を広げられます。 APIでは認証や権限に関する不備も代表的なリスクとなるため、ステータスコードやレスポンスを見るだけではなく、 アクセスしてよい利用者だけが適切なデータを取得できるか という視点も必要です。 さらに障害発生時にログを追えると、問題が画面、API、データベース、外部サービスのどこで起きたのか切り分けやすくなります。 最初からすべてを習得するより、現在の仕事に近いSQLやAPIから一つずつ身につけるほうが実務へつなげやすいでしょう。 金融知識は全部覚えるのではなく担当サービスから身につける！ 暗号資産取引所へ関わるために、銀行、証券、決済、ブロックチェーンなど金融分野の知識を最初からすべて覚える必要はありません。 まずは担当する機能について、 誰が、何を、どの条件で取引し、どのデータや資産が変化するのか を理解することが重要です。 売買機能を担当するなら注文から約定、残高反映までを整理し、入出庫機能を担当するなら暗号資産がどのような条件で外部へ移転されるのかを確認していきます。 また、暗号資産交換業者には利用者保護だけでなく、マネー・ローンダリングなどへの対策も求められており、本人確認や取引監視が業務上重要な意味を持ちます。 専門用語を暗記するだけでは、テストケースへ落とし込むことは難しいため、実際の取引フローと結びつけて覚えることがポイントです。 金融知識が増えるほど、「仕様書に書いてあるとおりか」だけでなく、 金融取引として不自然な挙動ではないか まで考えられるようになります。 テスト自動化は繰り返し確認する品質を効率化する手段！ 暗号資産取引所では機能追加や仕様変更が行われるたびに、既存機能へ影響がないか確認する回帰テストが必要になります。 毎回同じ操作や確認を手作業で繰り返していると工数が増えるため、条件が安定したテストは自動化の候補になります。 特にAPIテストは画面操作に依存しにくいため、自動テストへ組み込みやすい領域の一つです。 ただし、自動化率を高くすること自体が目的になると、頻繁に仕様が変わる機能まで自動化して保守工数が増える場合があります。 また、外部サービスや特定のデータ状態へ依存するテストでは、自動テストを書く前に 再現可能なテストデータや環境を作れるか を考える必要があります。 探索的に異常な挙動を探すテストは人が行い、繰り返し同じ結果を確認するテストを自動化するなど、目的に合わせた使い分けが重要です。 自分にもできる？暗号資産取引所の案件へ挑戦する前に準備しよう！ 暗号資産取引所の求人や案件を見たときは、「暗号資産経験あり」「金融経験あり」といった単語だけで応募可能か判断しないことが大切です。 同じ品質保証でも、決められたテストケースを実施する仕事と、仕様からテストを設計する仕事、品質プロセス全体を改善する仕事では求められる経験が異なります。 現在の暗号資産取引サービスでは、品質保証担当者が要件定義など上流工程へ参加し、開発プロセスそのものを改善する取り組みも行われています。 つまり、「暗号資産取引所のテスター」という職種名だけを見ても、実際の業務レベルまでは判断できません。 仕事内容を確認したうえで、現在持っているテスト経験、技術スキル、業務知識を分けて整理すると、 今すぐ対応できる部分と学習が必要な部分 が見えやすくなります。 金融経験必須という言葉だけで判断せず仕事内容まで確認する！ 求人や案件を見る際は、最初に担当工程を確認することが重要です。 テスト実施が中心なら、テストケースを理解して正しく実行し、不具合を報告する経験が主に求められます。 テスト設計まで担当する場合は、仕様からテスト条件を抽出し、正常系、異常系、境界値などを整理する力が必要になります。 さらに品質改善やリーダー業務まで含まれる場合は、不具合傾向の分析、開発プロセスの改善、他職種との調整なども担当範囲になり得ます。 暗号資産取引サービスの品質保証組織でも、テスト実行だけから上流工程を含む品質保証へ役割を広げる取り組みが進められています。 必須条件と歓迎条件を分け、金融経験の不足をウェブテスト、開発経験、SQL、APIなど別の強みで補えるかを見ること が、案件選びでは大切です。 応募前に五つの項目を棚卸しすれば現在地が見えてくる！ 応募を検討する際は、まず テスト実施、テスト設計、技術スキル、業務知識、品質改善 の五つに分けて経験を整理すると判断しやすくなります。 テスト実施では、仕様を理解して期待結果と実際の結果を比較できるかを確認します。 テスト設計では、正常系や異常系、境界値、状態遷移などからケースを作った経験があるかを振り返ります。 技術スキルではSQL、API、ログ確認、自動テストなど、画面操作以外に対応できる領域を書き出します。 業務知識では金融だけに限定せず、決済、会員管理、本人認証、高トラフィックサービスなど近い経験がないか確認するとよいでしょう。 最後に不具合分析や再発防止、テスト工程の改善経験まで整理し、 不足している項目を「応募前に必要なもの」と「参画後に学べるもの」に分けること で、必要以上に暗号資産案件を難しく考えずに済みます。 市場価値を高めるなら金融と品質保証の専門性を育てよう！ 暗号資産取引所で経験を積むメリットは、単に新しい業界でテスト経験を一つ増やせることだけではありません。 顧客資産を扱うサービスでは、機能品質だけでなく、セキュリティ、システムリスク、監査や証跡など幅広い視点が求められます。 実際の暗号資産取引サービスでも、品質保証担当者が上流工程へ参加して仕様の矛盾を早期に見つけ、開発プロセス全体へ働きかける方向へ役割が広がっています。 まずテスト実施から入り、次にテスト設計、SQLやAPI、障害分析、自動化へと対応範囲を広げれば、「画面を確認する担当者」から システム全体の品質を考えられる人材 へ成長できます。 そこへ暗号資産や金融取引の業務知識を組み合わせることで、一般的な品質保証経験だけでは得にくい専門性も築きやすくなります。 将来的にテストリーダーや品質改善、テスト自動化などを目指す場合にも、暗号資産取引所の複雑なシステムを経験することはキャリアの選択肢を広げる材料になります。 まとめ 暗号資産取引所のテストでは、画面や機能が仕様どおり動くだけでなく、 顧客資産、取引データ、外部連携、認証・権限、性能まで含めて安全に取引できるか を確認する必要があります。 特に注文や入出金では、処理前後の残高や履歴に矛盾がないか、通信障害や再操作が発生しても二重処理にならないかといった視点が重要です。 一方で、テストケース作成、テスト実施、不具合報告、仕様確認など、これまでウェブやアプリの品質保証で身につけた経験も十分に活かせます。 暗号資産の知識をすべて覚えてから挑戦するのではなく、担当機能の取引フローを理解しながら、SQL、API、ログ確認など必要な技術を段階的に増やすほうが実務へつなげやすくなります。 暗号資産交換業者ではサイバーセキュリティの重要性も一段と高まっており、品質保証が担う領域も単純なテスト実行だけにはとどまりません。 まず現在の経験を棚卸しし、 すでにできることと不足していることを整理したうえで案件を判断すること が、暗号資産取引所の品質保証へ進む現実的な第一歩です。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）