Fuse Onlineに見るコントラクトファーストの考え「API設計の進め方」

本記事では、システム間連携をサポートするために開発されたツールであるFuse Onlineを通して、API設計の進め方の考えの一つであるコントラクトファーストという考え方を紹介したいと思います。

こんにちは、NADP（Nissho Application Digital Platform）の原木です。（NADPについてはこちら）

昨今のシステム開発では、異なるシステムを組み合わせることで新規ビジネスを生み出すシステム間連携は欠かせません。システム間連携とは単純にシステム同士を繋ぐという話のみならず、そのシステムを裏で支えているチーム同士を繋ぐということでもあります。技術だけに留まらず開発プロセスや、コミュニケーション、マネジメントに至るまで意外と奥が深い話です。

そんなシステム間連携に伴う案件で困ることの一つが、異なるチーム同士でのデータのやり取り=API設計をどのように策定していくかというプロセスです。

この記事では、システム間連携をサポートするために開発されたツールであるFuse Onlineを通して、API設計の進め方の考えの一つであるコントラクトファーストという考え方を紹介したいと思います。

この記事では紹介しませんが、Fuse Onlineの重要な設計思想の一つに、「Enterprise Integration Patterns」（以下、略称EIP）があります。

EIPとは、Gregor Hohpe氏によりまとめられたシステム間連携に関するアーキテクチャパターンです。Fuse Online及びFuseがベースとしているCamelフレームワークはEIPの実現を手助けするために開発されました。

この記事ではEIPの詳細には踏み込みませんが、Fuse Onlineを理解するために必要な知識です。詳しく知りたい方はGregor Hohpe氏が運営されている下記のウェブサイトをご参照ください。
Enterprise Integration Patterns

一般的にモダナイゼーションなどのシステムへの投資は、

• システムの投資によりどのようなビジネスの機会が生まれるのかアイディアを着想する
• 着想したアイディアに基づき、経営者やアナリストが戦略を描く
• 描かれた戦略に基づき、具体的な要件をシステムに落とし込んでいく

といったステップで行われます。

ここで重要なのが、経営戦略から降りてきた構想にシステムの具体的な実装方法やデータ形式への詳細な規定がないことです。最近はフィジビリティやPoCなどのステップにより実現可能性を検討してからこのフェーズに入るのが通常ですが、それでもこのフェーズでシステム要件を作成する際に初めて直面する課題は減りません。

その中でよく議論に上がるのがAPIの設計、つまり、システム間でどのようにデータのやり取り、あるいは呼び出し方を規定するか？という話です。

すべての機能が入ったフルパッケージのシステムを1から開発することが昨今は非常に少なくなっています。既存のレガシーな業務アプリケーションを活用しつつ、一方で最先端のSaaS（例えばSalesforce等）をうまく組み合わせることでシステム投資を抑えつつ、新たなビジネスの創作を可能にするシステム連携を前提とした開発が主流です。

その場合、システムごとに開発者が違うケースは珍しいことではありません。したがってシステム間連携を実現するにあたり、チーム同士のコミュニケーションを円滑に図るため共通認識を作ることは非常に重要な観点です。システム間連携を支えるAPI設計においても、どのように作業を進めれば良いかAPIの具体的な実装方法と共に長い間思案されてきました。

システム間でのAPIの設計に関して、進め方は一般的に二種類あるといわれています。

• コントラクトファースト開発（スキーマファースト開発）
• コードファースト開発

例えば、コンソール画面からデータを取得する簡単なウェブアプリケーションを想像してみます。

コントラクトファースト開発では、どのようなデータを取得できるか、そしてその取得のためにどのような手順を描けばよいか、いわゆるインターフェースについて開発の最初に綿密な設計を行い（図1-①）、それに従うようにデータの入出力を行う具体的な処理を検討します（図1-②）。

コードファースト開発では、その逆です。データの処理方法について最初に実装を行い、その後インターフェースについて設計します。

両者にはそれぞれメリット・デメリットが存在し、APIで解決したい技術的・戦略的ニーズによって選択する開発手法は異なります。OpenAPIと呼ばれるRESTful APIをドキュメント化する仕様策定に携わったSwagger社により、次のように説明されています^*1。

デザインファースト開発（注: コントラクトファースト開発のこと）を選択したいケース

• 開発者エクスペリエンスが重要な場合
• ミッションクリティカルなAPIを提供する場合
• APIの使用者と実装者の間で良好なコミュニケーションを確保する場合

コードファースト開発を選択したいケース

• APIを開発する速度感を重視したい場合
• チームや会社など内部で使用するAPIを開発したい場合

これから紹介するシステムインテグレーションツールであるFuse Onlineは、コントラクトファーストアプローチに従って製品が開発されています。

Fuse OnlineでAPIを開発する場合を例に、コントラクトファーストアプローチを体感してみます。

例えば、ERPシステムであるGranditのデータベースから得意先企業のコード情報に紐づく見積り情報の一覧を取得するAPIサービスをFuse Onlineで構築してみるケースについて順を追って確認してみましょう。

AI導入の効果を最大化するためには、単にAIモデルを組み込むだけでなく、業務アプリケーション自体をAIとの連携を前提とした設計に見直すことが求められます。

• 審査業務アプリケーション
  • 与信スコアや真贋判定など、複数モデルとの連携
  • 判断根拠を明示するUIの実装
• 債権管理業務アプリケーション
  • 延滞予測モデルとの連携
  • 督促チャネル拡大と最適化
  • AIオペレーターの活用
• 不正検知業務アプリケーション
  • 加盟店やカードブランドとの対応履歴トラッキング
  • タスク期限管理とワークフローによる自動化

こうした高度なアプリケーションを自社で構築・運用していくには、理想としては外部ベンダーへの依存を減らし、内製化を進めることが望まれます。ただ、技術進化のスピードを考慮すると、外部ベンダーと連携しながら柔軟に体制を整えていく現実的なアプローチも必要です。

現在、カード会社の多くが審査・債権管理・不正対応といった業務の一部、または全部を外部ベンダーに業務委託しています。しかし、AI技術の進展により、自社の判断基準や戦略に沿ったロジックの構築・運用がしやすくなっており、内製化への関心が高まりつつあります。

特に不正対応の分野では、スピードと柔軟性が求められるため、標準化しづらい業務ほど内製化による効果が大きいと考えられます。

もっとも、すぐにすべてを内製化するのは難しいため、まずは外部ベンダーと連携しつつAI導入を進め、社内に企画・開発・運用・監査の体制を整えていく段階的な移行が現実的です。

（1）EUのAIガバナンス（AI Act）

EU圏内に拠点がなくとも、グローバル展開を志向する企業にとってはAI Actの規制対象となる可能性があります。特に外部ベンダーにAI開発を委託するケースでも、開発者と提供者の両方に説明責任が求められる点は注意が必要です。

• 成立： 2024年5月
• 発効日： 2024年8月1日
• 段階的な適用スケジュール：
  • 2025年2月2日：禁止AIに関する規制
  • 2025年8月2日：汎用目的AI（GPAI）への規制
  • 2026年8月2日：高リスクAIを含む一般規定の適用
  • 2027年8月2日：一部の高リスクAIに対する追加規制

なお、クレジットスコアリングは「高リスクAI」に分類され、バイアス対策や判断根拠の説明、人的監督、運用記録の保持などが求められます。

（2）日本におけるAIガバナンスの動き

EUのルールが国際標準となった場合、日本でも罰則付きの規制が導入される可能性があります。金融業界においては、透明性・説明責任・監査可能性の確保が今後さらに重要となるでしょう。

• AI事業者ガイドライン（第1.0版）： 2024年4月19日発表（総務省・経産省）
• 第1.1版（最新版）： 2025年5月8日公表
• 現状： 努力義務ベースで罰則なし
• 主なポイント： 説明責任、偏見排除など

AIは、単に業務を効率化するためのツールではなく、企業の競争力や業務のあり方そのものに関わる「経営資源」として位置づけられる時代がやってきます。

クレジットカード業界では、審査・債権管理・不正利用対策といった基幹業務の質がそのまま顧客体験や信用リスクにつながるため、AIの活用はもはや経営戦略における最重要課題と言えるのではないでしょうか。

私たち双日テックイノベーションは、AIの業務活用における課題解決をご提案いたします。まずはお気軽にご相談ください。

本記事の内容は2025年６月時点のものであり、状況の変化により変更となる場合があります。