ファンクション‐アズ‐ア‐サービス【function as a service】
ファース【FaaS】
FaaS
別名：ファンクションアズアサービス
FaaSとは、クラウド上で機能（関数）の実行環境を提供するサービスのことである。関数を使える環境の提供に特化したクラウドサービスとも表現し得る。
FaaSはアプリケーションサービスを運用するためのコンピュータ資源（運用インフラ）を提供するクラウドサービスである。同種のサービスとしては、これまでにもIaaS（Infrastructure as a Service）やPaaS（Platform as a Service）と呼ばれるサービスが登場している。ただしIaaS、PaaS、およびFaaSは、サービスの提供範囲が異なる。
IaaSは、クラウド上のハードウェアリソースに置かれているOSからアプリケーションまでのソフトウェア資源が提供され、OSレベルからユーザー側で管理する（できる）。PaaSはOSやミドルウェアは提供者側の管理下に置かれ、ユーザーはアプリケーションソフトウェアと、そのアプリケーションを運用するフレームワークのみ管理する（できる）ようになっている。そしてFaaSは、フレームワーク部分の管理も提供者側に任せ、利用者側は実行コードのみ扱えば済むように設計されている。
FaaSでは、コンピュータリソースや実行環境といった基盤部分の整備や管理は提供者側に委ね、利用者はプログラムをどう動かすかという部分にのみ注力できることになる。サーバーの運用という要素を希薄化した（サーバーレス）のサービス運用の実現により近いあり方として注目されている。
ちなみに、2010年前後には、いわゆるネット詐欺などのオンラインで行われる犯罪行為に関連して犯行に必要な資源やサービスを提供するシステムが「Fraud as a Service」（サービスとしての詐欺）という意味でFaaSと呼ばれていたことがある。
参照リンク
昨今注目される新たなクラウドアーキテクチャ「FaaS」とは - さくらのナレッジ
サーバーレスアーキテクチャ概論 - 株式会社WHERE IoT基盤センター 仲山昌宏
| ネットワーク犯罪： | ウォーダイヤリング Cybercrime Convention DNSキャッシュポイズニング FaaS ハイテク犯罪 ハイテク犯罪対策室 パケット盗聴 |
Function as a service
出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2026/06/10 23:32 UTC 版)
Function as a service（ファンクションアズアサービス、略:FaaS）は、 ISO/IEC 22123-2定義によると、ユーザーが「スケーラビリティのための初期投資を抑えつつ、マイクロサービスアプリケーションを構築および管理する」ことを可能にする「プラットフォームレベルのクラウド機能」である[1]。
Function as a Serviceは、サーバレスコンピューティングエコシステムのサブセットである[2]。
アンチパターン
「砂の粒（Grain of Sand）アンチパターン」とは、システム内に小さなコンポーネント（関数など）を大量に作成することを指す。これは、多くの場合、複雑さの増大、運用上のオーバーヘッド、およびパフォーマンスの低下を招く原因になる[3]。
これに関連するアンチパターンである「Lambdaピンボール」は、サーバレスアーキテクチャにおいて、関数（AWS LambdaやAzure Functionsなど）が断片化されたチェーンの中で互いを過剰に呼び出す場合に発生する現象である。これにより、レイテンシ、デバッグやテストの課題、そして可観測性の低下が引き起こされる[4]。これらのアンチパターンは、分散モノリスを形成することにつながる。
これらのアンチパターンへの対策として有効なのが、「パブリック（Public）インターフェース」と「パブリッシュ（Published）インターフェース」を明確に区別し、適切なドメイン境界を設けることである[4][5]。
パブリックインターフェースは、メソッド、クラス、APIエンドポイント、トリガーなど、技術的にアクセス可能なインターフェースであるが、正式な安定性を保証するものではない。一方、パブリッシュインターフェースは、正式なバージョニング、詳細なドキュメント、定義された非推奨ポリシー、および多くの場合は後方互換性のサポートが含まれます。また、複数バージョンを同時に維持することや、互換性を損なう変更（破壊的変更）を行う際に、正式な非推奨プロセスを踏むことが求められる[5]。
関数呼び出しが細切れに連なるチェーンは、サーバーレス関数が複雑なパターンで他のリソースと相互作用するシステムでよく見られ、「スパゲッティアーキテクチャ」や「分散モノリス」と呼ばれる。 一方、境界が明確なシステムでは、サーバーレス関数を凝集度の高い（まとまりのある）グループとして組織化する。そして、グループ内の通信は内部のパブリックインターフェースで管理し、グループの境界を越える通信のみを公開インターフェースとして定義する。このように区別することで、安定性の保証やメンテナンスへのコミットメントが明確になり、依存関係の複雑さを軽減できる[4][5]。
さらに、サーバーレス関数を過剰につなぐパターンへの対抗策として、個々の関数（コード）を書くのではなく、クラウドベンダーの「ネイティブ機能の統合」を重視するアーキテクチャ戦略（ファンクションレス・マインドセット）が採用されることもある。 ただし、このアプローチは学習コスト（学習曲線）が高くなる傾向があり、機能の制限や仕様が同じクラウドベンダーのエコシステム内であってもサービスごとに異なる点に注意が必要である[2]。
移植性の問題
Function as a serviceのワークロードは、ベンダーとの強固な統合によりサービスロックインになり、移行の障害に直面する可能性がある。ヘキサゴナルアーキテクチャは、ワークロードの移植性を促進することができる[6]。
関連項目
脚注
- ↑ “ISO/IEC 22123-2:2023 (E) - Information technology — Cloud computing — Part 2: Concepts”. International Standard: 25.
- 1 2 Brisals, Sheen (2024) (英語). Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions. O'Reilly Media. ISBN 978-1098141936
- ↑ Richards, Mark (2015) (英語). Microservices AntiPatterns and Pitfalls. O'Reilly Media
- 1 2 3 “Technology Radar Vol. 21 – An opinionated guide to technology”. Technology Radar (ThoughtWorks) 21 2026年6月9日閲覧。.
- 1 2 3 Fowler, Martin (2002). “Public versus Published Interfaces”. IEEE Software 19 (2): 18-19. doi:10.1109/52.991326 2026年6月9日閲覧。.
- ↑ Cui, Yan (2020) (英語). Serverless Architectures on AWS (2nd ed.). Manning. ISBN 978-1617295423
|
|
|
|---|---|
| SaaS | |
| PaaS | |
| IaaS | |
| 複数対応 |
|
| 技術 | |
- function as a serviceのページへのリンク
