APIインタラクションから価値を引き出すには、多くの場合、目的の結果を達成するために単一のエンドポイントへの呼び出し以上のものが必要です。最近まで、標準および仕様のコミュニティは、単一または複数のAPIによって公開されたエンドポイントを横断する複数回の呼び出しによる探求をどのように実現可能に明確にするかについて、ほとんどガイダンスを提供していませんでした。OpenAPIなどの一般的なAPI仕様を扱っている場合でも、APIコンシューマが統合作業を達成する能力を向上させるために、人間中心のガイドを作成する必要があることがよくありました。この問題やAPI環境におけるその他の一般的な実際的な課題に対処するため、OpenAPIイニシアティブ（OAI）のようなプロジェクトは、特別利益団体（SIG）、別名ワーキンググループの設立により、その重点分野を拡大しました。マルチステップワークフローシナリオに焦点を当てたワーキンググループの1つが、2024年5月にArazzo Specification 1.0.0のリリースにより、OpenAPI Initiativeをマルチ仕様プロジェクトへと進化させました。
実際、2024年にOAIは、Arazzo 1.0.0だけでなく、Overlay 1.0.0、さらにOpenAPI Specificationの重要な2つのパッチバージョンである3.1.1と3.0.4もリリースし、活動の新たな基準を打ち立てました。この勢いは2025年にも引き継がれ、Arazzo 1.0.1の最近のパッチリリースがそれに続きます。
Arazzoのより広範なユースケース
ArazzoはAIベースのAPI消費を可能にする重要な要素である一方で、今日のAPIプロデューサーとコンシューマーにとっていくつかの主要な課題にも対処しています。
- 確定的なAPI消費レシピの提供：繰り返しの可能な構造化されたAPIインタラクションを保証するためにワークフローを標準化します。
- 生きているワークフロードキュメントとして機能：古くなったドキュメントや外部のドキュメントに頼ることなく、APIワークフローを最新の状態に保ちます。
- コンシューマー向けドキュメントの自動化：開発者ポータルドキュメントを動的に生成することで、帯域外ドキュメントへの依存を減らします。
- エンドツーエンドテストの自動化を可能にする：自動テストに使用できるAPIワークフローを定義します。
- 規制コンプライアンス検証の合理化：コンプライアンス要件に対するAPIインタラクションを検証するためのチェックを自動化します。
- 次世代API SDKの生成を強化：特定のユースケースに焦点を当てた改善された開発者エクスペリエンスのためのワークフロー対応SDKを可能にします。
- エージェントAPI消費を可能にする：AIモデルとエージェントがAPIと対話するための、一貫性があり相互運用可能なメカニズムを提供します。
Arazzo Specificationは、デザインファーストやコードファーストといった特定の開発プロセスを義務付けるものではありません。代わりに、OpenAPI Specificationを使用して記述されたHTTP APIとの明確なワークフローインタラクションを確立することで、どちらのテクニックも容易にします（将来的にはイベントベースのプロトコルとAsyncAPI仕様にも拡張される予定です）。
Arazzoの多くのユースケースのいくつかに基づいて説明したので、次に仕様自体を詳しく見ていきましょう。
図1 - Arazzo仕様ロゴ
Arazzo仕様の構造
Arazzo仕様は、ユースケース指向のワークフローをプログラムで読み取り可能な形式で記述するアプローチを説明しています。Arazzoがサポートする形式はYAMLとJSONであり、これらは機械可読であると同時に十分に人間可読でもあります。Arazzoの文脈でワークフローについて語るとき、それは、いくつかのビジネス目標を達成するために織り合わせられた一連のAPI呼び出しとして定義されます。
Arazzoの人間可読性も相まって、APIプロバイダーはAPIのストーリーをコンシューマーの体験を向上させる方法で伝える能力が向上します。Arazzoは意図的に人間の開発者に対応し、その開発者体験（DX）を向上させます。同時に、ArazzoはAIエージェントのニーズを完全に認識しており、複雑な、または機密性の高いAPIワークフローを解析および実行するために必要な決定論的セマンティクスを提供することで、エージェント体験（AX）を同時に向上させます。
OpenAPI Specification (OAS) や、その姉妹仕様であるAsyncAPIに精通している方にとって、Arazzo Specificationは馴染み深いものに感じるでしょう。OpenAPIの$refメカニズム（JSON Schemaのキーワード$refと衝突する）を使用する代わりに、ArazzoはJSON Schemaオブジェクトではない参照を指定するためにランタイム式構文を使用します（JSON Schemaオブジェクトの参照には、JSON Schemaで明確に定義されているため、引き続き$refを使用してください）。詳細はこちらではなく、GitHub issueで確認できます。
ほとんどの場合、メタデータオブジェクト、再利用可能なコンポーネント、および仕様言語自体に関するさまざまな慣例やパターンは、馴染み深いものに感じるはずです。
以下の画像（ページ上の仕様スタイル）でさえ、馴染み深いものに感じるはずです！
図2 - Arazzo仕様 - 1.0.1
Arazzoの記述を作成するということは、YAMLまたはJSONドキュメントを（手作業で、あるいは好ましくはローコード、ノーコード、または自然言語処理ツールからの出力として）作成し、それがArazzo仕様に準拠していることを意味します。つまり、ドキュメントが有効なArazzoドキュメントとして分類されるためには、最低限、有効なArazzo仕様フィールド（例: `arazzo: 1.0.1`）、`info`フィールド、少なくとも1つのSource Description Objectが定義された`sourcesDescriptions`フィールド、および`workflows`フィールドに少なくとも1つのWorkflowが定義されている必要があります。
以下のセクションでは、これらすべてについて説明します。心配しないでください、複雑ではありません！
Arazzo仕様オブジェクト
これはArazzo記述のルートオブジェクトです。使用されているArazzo仕様のバージョン、さまざまなメタデータ、および処理ソフトウェアによって解析、レンダリング、および/または実行できるワークフローを識別します。
図3 - Arazzo仕様オブジェクト - 最小限の例
上記の例は、有効なArazzoドキュメントの最小限の例を示しています。このドキュメントには有効な`arazzo`バージョンが含まれており、この場合はリモートサーバー上のOpenAPI記述を参照する`sourceDescriptions`を指定し、少なくとも1つのステップを持つワークフローを定義しています。
Arazzoの仕様は、major.minor.patchのバージョン管理スキームを使用しています。この記事執筆時点でのArazzoの利用可能なバージョンは、1.0.1（2025年1月リリース）と1.0.0（2024年5月リリース）です。
|
フィールド名
|
説明
|
必須
|
|
arazzo
|
Arazzo記述が使用するArazzo仕様のバージョン。
|
はい
|
|
info
|
Arazzo記述に含まれるワークフローに関するメタデータを提供します。
|
はい
|
|
sourceDescriptions
|
定義されたワークフローが適用されるソース記述（OpenAPI記述など）のリスト。
|
はい
|
|
workflows
|
sourceDescriptionsで定義されたさまざまなAPIエンドポイントに適用されるワークフローのリスト。
|
はい
|
|
components
|
Arazzo記述のさまざまな再利用可能な要素/スキーマ - 冗長性を軽減するのに役立ちます。
|
いいえ
|
Arazzo構造 – 情報オブジェクト
Infoオブジェクトには、定義されたArazzoドキュメントに関するメタデータが含まれています。この情報は、Arazzoを使用して記述されたユースケース指向の機能を検出可能にし、カタログやマーケットプレイスを構築するのに役立ちます。
図4 - Arazzo仕様 - 情報の例
上記の例は、豊富なInfo Objectの例を示しており、title、summary、およびdescriptionフィールドが、コンシューマが現在のArazzoドキュメントで何が可能かを理解できるように明確なコンテキストを設定しています。versionフィールドは現在のドキュメントのバージョンを表しており、Arazzo仕様自体のバージョンと混同しないでください！
|
フィールド名
|
説明
|
必須
|
|
タイトル
|
Arazzoドキュメントの人間が読めるタイトル。
|
はい
|
|
概要
|
達成できることの短い要約。
|
いいえ
|
|
説明
|
定義されたワークフローの目的の説明。
|
いいえ
|
|
バージョン
|
ドキュメントのバージョン識別子（これはドキュメントが準拠する仕様のバージョンではありません）。
|
はい
|
Arazzo構造 – ソース記述オブジェクト
Arazzoドキュメントには、Source Description Objectsの配列であるsourceDescriptionsプロパティが含まれています。これは、OpenAPI記述または別のArazzoドキュメントのいずれかであるソース記述をリストし、定義された1つ以上のワークフローによって参照できます。プログラミング言語の観点からは、これらをnamespacesやimportsに似たものと考えるのが最適です。これらは、エントリArazzoドキュメントのワークフローが適用できる範囲（または境界）を設定します。
図5 - Arazzo仕様 - SourceDescriptionsの例
上記の例では、2つのOpenAPI sourceDescriptionsが指定されています。定義されているどのワークフローも、参照されているいずれかまたは両方のOpenAPI記述の操作と対話するステップを持つことができます。これは非常に強力です！
|
フィールド名
|
説明
|
必須
|
|
名前
|
ソース記述の一意の名前。
|
はい
|
|
URL
|
ワークフローで使用されるソース記述へのURL。Arazzoドキュメントに対する相対パスでも構いません。
|
はい
|
|
タイプ
|
ソース記述のタイプ。可能な値は "openapi" または "arazzo" です。将来的には "asyncapi" も追加する予定です！
|
いいえ
|
Arazzo構造 – ワークフローオブジェクト
Arazzoドキュメントには、workflowsプロパティで指定された1つ以上のワークフローオブジェクトを含めることができます。これらは、特定の目的または結果を達成するために、1つ以上のAPIを横断して実行されるワークフローを記述します。ワークフローの強力な点は、定義されたステップが複数のAPIにわたってホストされるAPIエンドポイント/操作への呼び出しで構成できることです。ワークフロー内のステップは他のワークフローを呼び出すこともできるため、モジュール性、保守性、テスト可能性を確保しながら、複雑なマルチワークフローオーケストレーションを簡単に連鎖させることができます。
図6 - Arazzo仕様 - ワークフローの例
上記の部分的な例では、単一のワークフローが定義されています。workflowIdはワークフローを一意に定義し、summaryとdescriptionは、そのワークフローがカバーするユースケースのコンテキストをコンシューマーに提供します。
以下のセクションでは、他のプロパティの詳細に踏み込みます。
|
フィールド名
|
説明
|
必須
|
|
workflowId
|
ワークフローを表す一意の文字列。
|
はい
|
|
概要
|
ワークフローの目的または目標を指定します。
|
いいえ
|
|
説明
|
ワークフローの説明。
|
いいえ
|
|
inputs
|
ワークフローが機能するために必要な入力（例：APIキー、トークン、または飛行したい目的地）。必要なものはJSON Schemaを使用して記述されます。
|
いいえ
|
|
dependsOn
|
このワークフローが処理される前に完了する必要があるワークフローのリスト。
|
いいえ
|
|
steps
|
ステップの順序付きリスト。各ステップは、API操作または別のワークフローへの呼び出しを表します。
|
はい
|
|
successActions
|
このワークフローで記述されているすべてのステップに適用可能な成功アクションのリスト。これらは、ステップが成功した場合に行うべきこと（例えば、すべてのステップ完了時にイベントを発生させるなど）と考えてください。
|
いいえ
|
|
failureActions
|
このワークフローのすべてのステップに適用可能な失敗アクションのリスト。良い例としては、認証トークンが期限切れのためにステップが失敗した場合、トークンを更新してステップを再試行することです。これを各ステップに記述するのではなく、便宜上ここに記述します！
|
いいえ
|
|
outputs
|
これらはワークフローから返されるものであり、呼び出し元のソフトウェアアプリケーションまたはエージェントによって処理できます。
|
いいえ
|
|
parameters
|
このワークフローで記述されているすべてのステップに適用可能なパラメータのリスト。
|
いいえ
|
Arazzo構造 – ワークフロー入力
ワークフローが自身で決定できないさまざまな入力を提供する必要があるのはよくあることです。たとえば、旅行を予約したい場合、目的地、日付、費用範囲（その他多数）の人間が入力する情報を提供する必要があります。さらに、ワークフローを実行するソフトウェアは、API呼び出しのための安全な資格情報なども渡す必要があるかもしれません。Arazzoは、JSON Schemaオブジェクトを使用してinputsを記述できるようにすることで、これを柔軟に処理します。
図7 - Arazzo仕様 - ワークフロー入力例
上記の例では、JSON Schemaオブジェクトがワークフローの期待される入力を記述しています。この場合、4つのstring入力が指定され、そのうち3つが必須です。
Arazzo構造 – ステップオブジェクト
ワークフロー内のstepsは、Arazzoドキュメントの最も重要な部分を表します。各ステップは、API操作への呼び出し、または別のワークフローへの呼び出しのいずれかを表します。後者は、ワークフローをモジュール化し、作成者がステップレベルで他の事前定義されたワークフローまたは検出可能なワークフローを活用することで、より複雑なワークフローを構築できるようにします。例として、OAuth 2.0ベアラートークンを取得するためのワークフローが存在する場合、作成された各ワークフローに完全な認証コードフローネゴシエーションをインラインで記述するのではなく、それを活用する方が有利です。
図8 - Arazzo仕様 - ステップ例
上記の部分的な例では、明確なdescriptionを含むsearchPetsステップがあります。このステップは、sourceDescriptionsで定義されたpetsAPI内のgetPets操作を呼び出します。ここでの構文は、Arazzo Specificationのランタイム式構文に従っています。
|
フィールド名
|
説明
|
必須
|
|
stepId
|
ステップを表す一意の文字列。
|
はい
|
|
説明
|
ステップの説明。
|
いいえ
|
|
operationId
|
sourceDescriptionsで参照されるAPI内に定義されたoperationId。
|
条件付き: operationIdまたはoperationPathまたはworkflowIdのいずれかが定義されている必要があります。
|
|
operationPath
|
sourceDescriptions内で参照されるAPIへのJSON Pointer参照（operationIdはOpenAPIで必須ではないため、操作を参照する他の方法が必要ですL）。
|
条件付き: operationIdまたはoperationPathまたはworkflowIdのいずれかが定義されている必要があります。
|
|
workflowId
|
sourceDescriptionsで参照されるArazzoワークフロー内（または現在のArazzoドキュメント内の別のワークフロー内）に定義されたworkflowId。
|
条件付き: operationId または operationPath または workflowId が定義されている必要があります。
|
|
parameters
|
このステップで参照される操作またはワークフローに渡されなければならないパラメータのリスト。
|
いいえ
|
|
requestBody
|
参照された場合、操作に渡すリクエストボディ。
|
いいえ
|
|
successCriteria
|
ステップの成功を判断するためのアサーションのリスト。
|
いいえ
|
|
onSuccess
|
ステップ成功時に何を行うかを指定する成功アクションオブジェクトの配列（特定の条件が真であれば、最後のステップにジャンプするかもしれません）。
|
いいえ
|
|
onFailure
|
このワークフローのすべてのステップに適用される失敗アクションオブジェクトの配列（回復して再試行するか、最初に別のワークフローを呼び出すかなど）。
|
いいえ
|
|
outputs
|
これらはステップから返されるもので、ワークフローの後続のステップで処理されたり、ワークフロー出力にマッピングされたりします。
|
いいえ
|
Arazzo構造 – ステップパラメータ
APIを呼び出すArazzoステップを定義する場合、通常、操作に特定のパラメータを指定する必要があるかもしれません。これらはHTTPヘッダー、クエリパラメータ、パスパラメータなどです。ArazzoはParameters Objectを通じてこれを処理します。
図9 - Arazzo仕様 - ステップパラメータの例
上記の例では、4つのクエリパラメータが定義されています。最初の3つのパラメータの値は動的で、inputsで定義されたプロパティからマッピングされています。statusプロパティの値はリテラル文字列（例: 「利用可能」）です。
|
フィールド名
|
説明
|
必須
|
|
名前
|
パラメータの名前。
|
はい
|
|
in
|
パラメータの場所。可能な値は "path"、"query"、"header"、または "cookie" です。コンテキスト内のステップがworkflowIdを指定する場合、すべてのパラメータはワークフロー入力にマッピングされます。
|
条件付き: ステップでoperationIdまたはoperationPathが指定されている場合は必須です。
|
|
値
|
パラメータに渡す値。値は定数またはランタイム式です。
|
はい
|
Arazzo構造 – ステップ成功基準
ステップが完了した後に何をすべきかを決定するには、そのステップが成功したかどうかを知る必要があります。これは単純なチェックである場合もあれば、API呼び出しによって返されたHTTPステータスコードをチェックしたり、応答ペイロード内の特定のコンテンツを検査したりするような、より複雑なものである場合もあります。successCriteriaは検証される条件のリストを指定します。指定されたすべてのアサーションが合格した場合、ステップは成功と見なすことができます。
図10 - Arazzo仕様 - ステップ成功基準の例
上記の例では、2つの条件が指定されています。ステップが成功と見なされるためには、両方がtrueと評価されなければなりません。最初の条件は、API呼び出しから返されるHTTPステータスコードが200である必要があることを指定しています。2番目の条件は、APIからの応答に、application/jsonタイプと予想される応答本文が含まれており、ペイロード内にルートレベルのペット配列があり、その長さが0より大きい必要があることを指定しています。
|
フィールド名
|
説明
|
必須
|
|
コンテキスト
|
適用される条件のコンテキストを設定するために使用されるランタイム式。
|
条件付き:
typeが指定されている場合、contextは提供されなければなりません。
|
|
条件
|
適用する条件。条件は単純なもの（例：$statusCode == 200のように、ランタイム式から取得した値に演算子を適用する）や、正規表現、またはJSONPath式である場合があります。正規表現またはJSONPathの場合、typeおよびcontextは指定されなければなりません。
|
はい
|
|
タイプ
|
適用される条件のタイプ。指定されている場合、許可されるオプションはsimple、regex、jsonpath、またはxpathです。
|
|
Arazzo構造 – 失敗アクションオブジェクト
人生と同じく、API呼び出しは常に期待通りにいくとは限りません。非ハッピーパスに対処できることは、Arazzo仕様の特定の強みです。ステップ内のonFailureプロパティを使用すると、APIがsuccessCriteriaプロパティで定義された条件を満たさないものを返した場合に何を行うべきかを指定できます。何も指定されていない場合、全体のワークフローは失敗した時点で停止します。
図11 - Arazzo仕様 - 失敗アクションの例
上記の例では、APIが参照されたステップによってHTTPステータスコード503（例：サーバー利用不可）を返した場合に実行されるretryタイプの失敗アクションを指定しています。設定に基づいて、現在のステップは1秒後に再試行されるべきであり（retryAfterで指定）、APIが引き続き503ステータスコードを返す場合、5回の試行後に再試行を停止すべきです（retryLimitで指定）。
|
フィールド名
|
説明
|
必須
|
|
名前
|
失敗アクションの名前。
|
はい
|
|
タイプ
|
実行するアクションのタイプ。可能な値は「end」、「retry」、または「goto」です。
|
はい
|
|
workflowId
|
ステップの失敗時に転送する既存のワークフローを参照するworkflowId。
このフィールドは、タイプフィールドの値が「goto」または「retry」の場合にのみ関連します。一般的な例としては、有効期限切れのトークンが原因でAPIがHTTP 401を返した場合、ここにリフレッシュトークンワークフローを参照できます。
|
いいえ
|
|
stepId
|
ステップの失敗時に転送するstepId。このフィールドは、タイプフィールドの値が「goto」または「retry」の場合にのみ関連します。
|
いいえ
|
|
retryAfter
|
ステップ失敗後、次の試行を行うまでの遅延秒数。
|
|
|
retryLimit
|
全体のステップが失敗する前に、ステップを再試行する試行回数を示す整数。
|
いいえ
|
|
criteria
|
このアクションが実行されるべきかどうかを判断するためのアサーションのリスト。
|
いいえ
|
typeフィールドには3つの可能な値があります。
end - ワークフローが終了し、コンテキストは呼び出し元に適用可能な出力とともに返されます。retry - 現在のステップが再試行されます。再試行は、retryAfterおよびretryLimitフィールドによって制約できます。goto - ワークフロー制御の片方向転送を指定されたラベル（workflowIdまたはstepId）に転送します。
Arazzo構造 – 成功アクションオブジェクト
デフォルトでは、ワークフロー内で指定されたステップは順番に実行されます。特定の状況では、いくつかのステップをスキップして実行を高速化し、提供されている価値をより早く享受するために必要な情報を持っていると判断できる場合があります。onSuccessプロパティは、この種の制御を可能にします。
図12 - Arazzo仕様 - 成功アクションオブジェクト
上記の例では、gotoタイプの成功アクションがあります。この例が示すのは、APIへのリクエストで条件に一致するペットが少なくとも1匹返された場合、joinWaitingListステップにジャンプできるということです。
|
フィールド名
|
説明
|
必須
|
|
名前
|
成功アクションの名前。
|
はい
|
|
タイプ
|
実行するアクションのタイプ。可能な値は「end」または「goto」です。
|
はい
|
|
stepId
|
ステップ成功時に転送するステップID。このフィールドは、タイプフィールドの値が「goto」の場合にのみ関連します。
|
いいえ
|
|
criteria
|
このアクションが実行されるべきかどうかを判断するためのアサーションのリスト。
|
いいえ
|
typeフィールドには2つの可能な値があります。
end - ワークフローが終了し、コンテキストは呼び出し元に適用可能な出力とともに返されます。goto - ワークフロー制御の片方向転送を指定されたラベル（workflowIdまたはstepId）に転送します。
Arazzo構造 – ステップ出力
ワークフローステップを実行する際、その後のワークフロー内のステップに情報を提供したいと考えることがよくあります。たとえば、製品を検索した場合、次のステップでそれをショッピングカートに追加できるように、その製品の識別子を利用できるようにしたいと考えるかもしれません。ステップoutputsは、単一の名前と動的な出力値の間のマッピングを含む配列です。
図13 - Arazzo仕様 - ステップ出力の例
上記の簡単な例では、petIdという一意の名前の出力を返し、その値は、ステップを処理するソフトウェアによって評価されるランタイム式によって定義され、ワークフローの後続のステップでペットの実際の識別子を利用できるようにします。
Arazzo構造 – ワークフロー出力
ワークフローoutputsは、ステップ内のものとまったく同じ原則に従います。唯一の違いは、処理の観点から、ワークフロー出力が呼び出し元コンテキストに返されることです。ソフトウェアアプリケーションがワークフローを実行していた場合、出力は評価、保存、またはレンダリングのためにアプリケーションに返されます。
図14 - Arazzo仕様 - ワークフロー出力の例
図15 - Arazzo内のその他の再利用可能なオブジェクト
例
Arazzo仕様を活用して、企業がAPI製品とコンシューマー向け機能を強化する方法の、架空の簡単な例を見てみましょう。そのために、架空の企業であるPetCoを想定します。
問題提起:
ビジネス上の問題を特定しました。ペットショップに捨てられるペットの数が多すぎて、圧倒されています。
提案された解決策:
広範な調査の結果、カタログ化したペットを検索し、引き取る機能を作成することにしました。この引き取りサービスを当社のウェブサイトを通じて提供し、当社の調査でそのようなサービスの必要性を表明した、ペットシェルター、ペットチャリティ、ペット孤児院といった広範なエコシステムにAPIを提供します。
当社のAPI:
組織構造に基づき、私たちは引き取りAPIを管理する新しいチームを設立しました。このチームは、コアのペットカタログ施設とは独立しています。したがって、提供しているAPIは以下の通りです。
- ペットAPI – ペットのカタログ化に必要なリソースとメソッドを提供します。
- 引き取りAPI – 引き取りの開始と管理に必要なリソースとメソッドを提供します。
図16 - ペットAPIの例
図17 - 引き取りAPIの例
ワークフロー
より広範な消費者のエコシステムにおける理解と利用を合理化するために、特定の基準に一致するペットを引き取るプロセスを明確にしたいと考えています。そのため、Arazzo仕様を活用して、以下の必要なステップを記述します。
- 特定の条件に基づいてペットを検索する。
- 養子縁組のリクエストを開始する。
- 養子縁組のステータスを更新して養子縁組を確認する。
- ペットのカタログエントリでペットが「利用可能」とタグ付けされていないことを確認して、養子縁組が完了したことを検証する。
以下のビデオでは、公開されているArazzo Specification GPTを活用して、Arazzoドキュメントの作成を高速化し、「ペットを飼う」製品を含むAPI Hub開発者ポータルを、ステップバイステップの開発者ドキュメントとクライアントコードサンプルで準備する方法を紹介しています。
図18 - SmartBearによるArazzo Specification GPT
結論
Arazzo仕様は、APIテクノロジーの未来において重要な役割を果たす準備ができています。多くのデジタルエコシステムに相互接続する洗練されたAPIの需要が高まる中、この仕様は複雑なシナリオを処理し、新興テクノロジー（AIなど）に対応する必要があります。実際、AI駆動のAPI消費への移行は、決定論的なAPIワークフローの必要性を加速させています。
ワークフローを自動化したり、AIの利用を可能にしたり、APIガバナンスを強化したりする場合でも、Arazzoは次世代のAPI駆動型イノベーションを解き放つ鍵となります。Linux Foundationの下、OpenAPI Initiative内のオープンスタンダードであるArazzoは、オープンかつ協調的な方法で進化し、業界のニーズをサポートし続けるよう位置づけられています。
Arazzoをサポートする活気あるツールエコシステムが出現しており、SmartBearではAPI Hub製品全体でArazzoへの幅広いサポートに取り組んでいます。それがリリースされるのを待てない場合は、ArazzoドキュメントのリンティングにSpectralをチェックし、OpenAI GPTストアでArazzo GPTを試してみてください。