APIは新たなCLIです。ただし、どのようなAPIを構築するかについては、宣言型が主流です。
API（アプリケーションプログラミングインターフェース）は、今日では不可欠な機能です。組織はビジネスレイヤーにAPIを導入し、パートナーとの統合や、いわゆる「市民開発者」によるイノベーションを促進しています。アプリケーションにもAPIがあり、統合を容易にするとともに、頻繁に変更される可能性があるビジネスロジックを、それほど頻繁には変更すべきでないインターフェースから分離しています。インフラストラクチャにもAPIが導入されています。スイッチやルーターから、アプリケーションサービス、ミドルウェア、データベースに至るまで、デリバリーおよびデプロイのパイプラインを構成するインフラストラクチャは、APIに対応しています。
このこと自体が、台頭しつつあるNetOpsコミュニティにとって何を意味するのか、立ち止まって考える十分な理由となります。組織は、いくつかの主要なアプリケーションインフラストラクチャコンポーネントに標準化する傾向がありますが、ネットワークおよびアプリケーションサービスのインフラストラクチャコンポーネントについては、少数の主要なものだけに標準化する可能性はそれほど高くないためです。
組織がアプリケーションの高速化とセキュリティ強化のために利用する平均16種類のアプリケーションサービスは、少なくとも数個を超えるインフラストラクチャコンポーネントによって提供されていることは確かです。1つのコンポーネントにつき3つのアプリケーションサービスを提供すると多めに見積もっても、5つの異なるデバイス、つまり5つの異なるAPIが必要です。
ここで問題となるのは、インフラストラクチャプロバイダーが「APIは新たなCLIである」という言葉を、やや文字どおりに受け取りすぎているケースが多いことです。つまり、APIはCLIを単にREST対応にしたものにすぎません。
インフラストラクチャの各コンポーネントでCLIを使用した経験があれば、CLIの操作体系がそのインフラストラクチャのオブジェクトモデルと密接に対応していることをご存じでしょう。APIは、この設計をそのままHTTPに移しただけにとどまることが少なくありません。そのため、APIを活用するには、対象デバイスのオブジェクトモデルも習得する必要があります。
この抽象化レベルが自動化とオーケストレーションの進展を妨げています。今や、自動化のスキルを持つ人材だけでなく、5つ以上の異なるネットワークインフラストラクチャモデルについて一定の専門知識を備えた人材を確保する必要があるためです。求められる専門性には、VLANの設定やルーティングに関する基礎的な理解から、仮想サーバー、仮想IPアドレス、ノード、メンバー、プール間の関係に至るまで、ドメイン知識も必要となる場合が少なくありません。
インフラストラクチャの根底にある複雑さが表面化すると、導入の促進や自動化の実現を妨げます。インターフェースは、モデルとロジックを抽象化し、その複雑さからユーザーや運用担当者を保護するものであるべきです。GUIでは、シンプルなサービスを構成する際にオブジェクト階層をたどる必要がないため、これを実現できます。
そのため、APIによって、この煩雑な階層移動が再び必要になっていると分かると、苛立ちを感じることが少なくありません。
この問題は、ネットワークおよびアプリケーションインフラストラクチャに限ったものではありません。実際、MuleSoftの調査「APIの価値の高まり」によると、API統合に関して顧客やパートナーから最も多く寄せられた要望は、「特定のビジネスニーズに適合するカスタマイズされたAPI」で、回答者の47%を占めました。次いで、より充実したドキュメント（19%）、「ノーコード」の統合テンプレート（19%）、必要かつ利用中のAPI向けSDKラッパー（13%）でした。
これらはすべて、簡素化を求める声に集約できます。そしてテクノロジーにおいて、簡素化とは抽象化を意味します。
ここで本稿の要点にたどり着きます。宣言型インターフェースこそが、その抽象化を実現するものです。現在、インフラストラクチャのプロビジョニング、構成、管理、統合に使用されているインターフェースを簡素化することで、宣言型インターフェースはインフラストラクチャを誰もが利用しやすいものにし、新たな可能性を切り開きます。
宣言型と命令型
一般に、宣言型と命令型はいずれもAPIの一種と考えられます。通常、APIと聞いて思い浮かべるのは命令型APIです。命令型APIでは、処理の実行方法を対象システムに具体的に指示します。たとえば仮想サーバーを追加する場合、5回、10回、あるいはそれ以上の個別のAPI呼び出しが必要であっても、その方法を一つひとつ具体的に指示します。
つまり、適切な属性を持つ特定のオブジェクト（たとえば、IPアドレスを持つノード）を作成するよう指示します。次に、そのノードを割り当てるプールを名前付きで作成するよう、別途システムに指示する必要があります。その後も指示が続きますが……もうお分かりでしょう。命令型APIを使用するには、システムとそのオブジェクトモデルだけでなく、意図した結果を得るために必要な手順も理解しなければならず、ユーザーに負担がかかります。
命令型APIでは、これが避けられない負担となります。
とはいえ、命令型APIが全般的に悪いわけではありません。GUIを構築する場合や、命令型APIが提供するような細かな制御を必要とする他のシステムと統合する場合には、非常に重要です。命令型APIも必要ですが、NetOpsやDevOps向けの自動化と統合には適していません。
しかし、それ以外の人にとっては、そこまで詳細に把握する必要はありません。実際、それほど深い知識を求めると、利用のハードルが上がり、オートメーションやオーケストレーションの取り組みが遅れる可能性があります。ましてや、特定のインフラストラクチャ領域を専門としないNetOpsにとってはなおさらであり、インフラストラクチャの民主化や、DevOpsおよび開発者向けセルフサービスモデルの実現には適していません。
そこで役立つのが宣言型APIです。
宣言型インターフェースでは、実行したい「内容」を指定し、ロジックとワークフローはシステムに委ねます。そのため、ノードとプールを作成し、必要なオブジェクトに対して適切なロジックをすべて実行するようシステムに具体的に指示するのではなく、それらとその関係を「記述」します。
宣言型インターフェースには、JSONを使用するものもあれば、XMLを使用するものや、今でも単純なフォームデータを使用するものもあります。いずれも、オブジェクトモデルやシステム階層をほとんど理解していなくても、データによってオブジェクトをシンプルかつ明確に記述できることを前提としています。
たとえば、この宣言は比較的読みやすいものです。オブジェクトモデルに関する基本的な理解は前提となりますが、この宣言を記述するために特定の製品の認定資格が必要になるほどではありません。
"web_pool": { "class": "Pool", "monitors": [ "http" ], "members": [ { "servicePort": 80, "serverAddresses": [ "192.0.1.10", "192.0.1.11" ] } ] }
宣言型インターフェースの価値は、インフラストラクチャのプロビジョニングと構成に必要なドメイン知識を減らし、複雑さを軽減できる点に表れます。必要な専門知識のレベルが下がることで、NetOpsはより迅速かつ効率的に作業できるだけでなく、DevOpsや開発者にもこの機能の活用を促せるようになります。
宣言型インターフェースをインフラストラクチャ管理の標準的な手法として採用すれば、セルフサービス機能や高度な自動化機能の提供に活用できる人材の幅がすぐに広がります。上記の宣言型インターフェースは、DevOps担当者や開発者が理解して利用するうえで、ほとんど説明を必要としません。一方、命令型インターフェースで成果を得るには、まずインフラストラクチャ固有のモデルとワークフローの習得に、より多くの労力を費やす必要があります。
宣言型インターフェースは、デプロイパイプラインの自動化や、システムと他のインフラストラクチャサービスとの統合に必要なプロビジョニング、構成、管理を簡素化し、インフラストラクチャを誰もが扱いやすいものにします。これにより、自動化をより迅速かつ効率的に進められるほか、NetOpsとDevOpsの取り組みからメリットを得るために必要な、運用領域を越えた連携と協力を促進できます。
著者について
Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事
SOAS 2025：足並みの乱れが凡庸さを招く
AI導入における方針の不一致は、非効率を招きます。セキュリティ、自動化、導入の各戦略を整合させ、AIの可能性を最大限に引き出す方法をご紹介します。
WebAssemblyが重要な理由
WebAssembly（Wasm）は、あらゆるプラットフォームで高性能なアプリケーションを実現する、ポータブルで高速かつセキュアなバイナリ命令セットです。
インフラストラクチャは依然として格好の攻撃経路
クラウドコンピューティングでは、APIやドラッグ＆ドロップ式の設定ツールを活用し、ネットワークやインフラストラクチャを敬遠する人がそれらを直接扱わずに済むようにすることで、インフラストラクチャへの対応を不要にすることが長年追求されてきました。しかし、インフラストラクチャを無視することも、攻撃の主要な標的であるという事実を見過ごすこともできません。
堅牢なデータアーキテクチャがもたらす戦略的メリット
適切に構築されたデータアーキテクチャがもたらす効果は、業務プロセスの改善にとどまりません。戦略的な業務効率の向上、より深いビジネスインサイトの獲得、隣接するビジネス機会への展開にもつながり、これらすべてをより俊敏に実行できるようになります。
デジタルワークフローにおける不正検知には、データだけでは不十分
2019年には、業界全体でクレジットカード詐欺の試みが約25万件確認されました。これは約2分に1件の割合です。今日、不正を検知するには、デジタルワークフロー上のできるだけ多くのポイントから収集したデータを相互に関連付け、手作業によるデータ処理をはるかに上回る速度で分析する能力が求められます。