【入門編】GraphQLとは？RESTとの主な違いや特徴をわかりやすく解説

ソフトウェア開発の領域では、開発効率の向上やリアルタイムなデータ連携などを目的として「API」の重要性が高まっています。

代表的なものとして「REST API」が挙げられますが、近年では「GraphQL」と呼ばれるアプローチにも注目が集まっており、多くの開発現場で採用されています。

ただ、GraphQL導入を検討するに当たり、「従来のREST APIとはどう違うのか？」「GraphQLはどういったケースに適しているのか？」と悩むケースも少なくありません。

そこでこの記事では、GraphQLの基礎知識やメリット、デメリット、REST APIとの違いを詳しく解説します。実際にどのようなシーンで活用すべきなのかも紹介するので、ぜひ参考にして下さい。

1. そもそもAPIとは？

まずGraphQLについて触れる前に、「APIとは何か？」という点について簡単に再確認しておきましょう。APIとは、「Application Programming Interface」の略語で、ソフトウェアコンポーネント間でデータや機能をやり取りするための規約・仕様を指します。つまり、APIは異なるアプリケーションやWebサービス同士をつなぐ橋渡し役として機能する技術です。

APIによってインターフェースが明確に定義されることから、フロントエンドとバックエンドを独立して開発・デプロイでき、それぞれ異なる技術スタックを選択することも可能になります。

GraphQLやRESTもAPI技術の一種であり、開発の要件や目的にあわせて正確な導入判断を行う必要があります。

2. GraphQLの基礎知識

APIについて理解したところで、GraphQLの基礎知識について解説します。ここでは、GraphQLの概要や仕組み、誕生した背景・歴史について紹介します。

2-1. GraphQLの概要・定義

GraphQLは、Facebook社（Meta社）によって開発されたオープンソースのAPI向けのクエリ言語であり、そのクエリを実行するサーバーサイドのランタイム（実行環境）です。なお、クエリ言語とは、データに対して問い合わせをするための言語の総称を指します。

クエリ言語としてはSQLがよく知られていますが、SQLはデータベースを操作・検索するための言語であり、GraphQLはAPIに対してクエリを実行して必要なデータを取得する技術になります。

2-2. GraphQLの仕組み

GraphQLは、クエリにより柔軟なデータ操作が可能で、必要なデータだけを抽出します。具体的には、クライアントが必要なデータを具体的に定義し、GraphQLサーバーはクライアントから受け取ったクエリの内容に応じて結果（データ）を返します。

GraphQLの仕組み・操作を理解するためには、GraphQLの構成要素とそれぞれの役割を把握しておくことが大切です。

2-3. GraphQLが誕生した背景と歴史

GraphQLは先ほども少し触れた通り、Facebook社（Meta社）によって開発・公開されたAPI技術です。

Facebookが生まれてから数年後、モバイルアプリが急速に普及したことをきっかけに、Facebook社はモバイルのニュースフィードをREST APIで開発し始めました。しかし、REST APIでの開発では、必要なデータを取得するのに複数回のリクエストのやり取りが必要になるなど、処理が複雑化してしまうという課題が発生していました。

その課題を解決するためにFacebook社は2012年にGraphQLの開発をスタートさせ、2015年にオープンソースとして公開するに至ったのです。

GraphQLならREST APIよりも効率よくデータを取得できる利便性があることから、公開以降現在では多くの企業で採用されています。

3. GraphQLのメリット・利点

開発現場においてGraphQLを利用するメリット・利点は以下の通りです。

• 必要なデータの取得
• データの一括取得
• バージョン管理の容易さ
• 型定義によるスキーマ駆動開発
• ドキュメントの生成・管理が簡単

3-1. 必要なデータの取得

GraphQLなら、クライアントがクエリで必要なフィールドを具体的に指定できるため、本当に必要なデータだけを取得できるメリットがあります。つまり、必要以上のデータが返されるオーバーフェッチの抑制・回避に繋がります。

例えば、ユーザー情報の取得においてIDとパスワードだけ欲しい場合、そのフィールドだけ指定すればそのデータだけ取得できます。この柔軟性により、無駄なデータを扱う必要がないため、通信量の削減にも繋げられます。

3-2. データの一括取得

GraphQLは、オーバーフェッチだけでなく、アンダーフェッチの解消にも繋げられます。アンダーフェッチは、データ取得のために複数回のリクエストをしなければならない状態です。

REST APIでアンダーフェッチが生じてしまうケースでも、GraphQLなら1回のリクエストで求めるデータを全て取得できるメリットがあります。

3-3. バージョン管理の容易さ

GraphQLはバージョン管理を簡素化できるメリットもあります。REST APIの場合は、仕様変更のたびに新しいエンドポイントを作成する必要があります。GraphQLなら新しいフィールドを定義するだけで済むため、既存クエリに影響を与えずAPIを段階的に拡張できます。

3-4. 型定義によるスキーマ駆動開発

GraphQLでは、スキーマによってAPIで利用可能なデータ構造が定義されます。それにより、フロントエンドとバックエンド間で共通の認識を持つことができ、連携がスムーズになります。

また、型を明確に定義するため開発ミスを事前に防ぎやすく、システムの安全性や保守性を維持することが可能です。

3-5. ドキュメントの生成・管理が簡単

GraphQLは自己文書化（self-documenting）なAPIであり、どのようなデータを扱えるかなどの仕様情報をスキーマを通して把握でき、簡単にドキュメントを生成することが可能です。ドキュメント整備はAPI開発において負担になりがちですが、GraphQLなら生成・管理コストを削減しやすいです。

また、新規の開発メンバーや外部の関係者にもAPI仕様を共有しやすくなります。

4. GraphQLのデメリット

GraphQLには以下のようなデメリットもあるため、事前に把握しておくことが大切です。

• 学習コストの高さ
• セキュリティの課題
• サーバー負荷の可能性
• モニタリングの複雑化
• N+1問題の発生

4-1. 学習コストの高さ

GraphQLは、学ぶべき内容が多いAPI技術です。GraphQLを扱うためには、クエリ言語やスキーマ設計、ミューテーション、リゾルバーなど、REST APIとは異なる用語や技術を理解する必要があります。また、GraphQL Federationを採用する場合は、さらに学習難易度が高くなります。

現状チーム内にGraphQLの経験・知識があるメンバーがいない場合は、教育コストも考慮しながら導入判断を行う必要があると言えるでしょう。

4-2. セキュリティの課題

GraphQLは柔軟なクエリで必要なデータを取得できますが、その柔軟性の高さがセキュリティリスクに繋がるケースもあります。例えば、悪意あるユーザーが不正なクエリを実行すればサーバーに過度な負荷がかかってしまいます。そのため、GraphQLを導入する際には適切なセキュリティ対策が必要です。

具体的な対策として、本番環境ではイントロスペクションクエリを無効化することが大切です。これが有効になっている場合、スキーマ全体が外部から閲覧可能になり、攻撃者に情報を提供してしまうためです。

また、認証（Authentication）と認可（Authorization）の実装が必須です。通常はJWTトークンをHTTPヘッダーに含めて認証し、各Resolverレベルで認可チェックを実装します。なお、フィールドレベルでのアクセス制御も可能です。

4-3. サーバー負荷の可能性

GraphQLはクエリを自由に記述できますが、クエリ設計によってはサーバー側の処理が複雑になる可能性があります。クライアントが意図せずに大量のデータをリクエストした場合、サーバーに大きな負荷がかかってしまいます。その結果、処理時間が長くなるなどパフォーマンス低下に繋がるため注意が必要です。

4-4. モニタリングの複雑化

GraphQLのモニタリングは、REST APIと比較すると複雑になります。主な要因として、GraphQLの場合は1つのエンドポイントに全てのリクエストが集約される形で処理され、パフォーマンス分析が難しくなるためです。

モニタリングの課題を解決するためには、GraphQL特化型APMの導入など専用ツールの導入が必要になります。

4-5. N+1問題の発生

N+1問題とは、簡潔に説明するとクエリの過剰発生のことで、本来であれば1回で済むはずだった処理が、追加の問い合わせによってパフォーマンスが低下する現象を指します。GraphQLでは、リゾルバーの独立性によってN+1問題が発生しがちです。

GraphQLにおけるN+1問題の解決方法としては、主に「DataLoader」と呼ばれるバッチ処理機能を持ったライブラリを使用します。

5. GraphQL Federationとは？

GraphQLの理解を深めるために、「GraphQL Federation」についても把握しておきましょう。ここでは、GraphQL Federationの概要や必要性について詳しく解説します。

5-1. GraphQL Federationの概要

GraphQL Federationとは、複数のGraphQLサービスを統合して1つのGraphQL APIとして利用できるようにする仕組みを指します。主にマイクロサービス環境で採用され、大規模開発における通信処理の複雑さの課題を解消するためのアプローチです。次でGraphQL Federationのメリットや必要性について詳しく触れていきます。

5-2. GraphQL Federationの必要性

大規模システムにおいては、サービス間の連携のためにシステム全体のAPI数が増えやすくなります。例えば、ユーザー管理・商品管理・注文管理など機能ごとにAPIが分散されるケースでは、フロントエンド側は複数のAPIからデータを取得する必要があり、作業の効率性が下がってしまいます。

そこでGraphQL Federationを利用すれば、分散されたAPIを1つのGraphQL APIとして統合できるため、フロントエンドは単一のエンドポイントを通して全てのデータにアクセスすることが可能になります。

また、機能ごとの各チームが独立してAPIを管理できるようになるため、GraphQL Federationはマイクロサービスアーキテクチャを採用する大規模プロジェクトで最大限に効果を発揮します。

6. REST APIとは？

GraphQL導入を検討する際には、REST APIについても把握しておくことが大切です。

REST APIとは、「Representational State Transfer」の略語で、Web上のデータをHTTP通信を用いて操作するWebアーキテクチャスタイルの一つです。

シンプルな実装が可能であることから、多くのWebサービスやアプリケーションで幅広く採用されています。なお、REST APIは、「RESTful API」や「RESTful Web API」とも呼ばれます。

次からREST APIのメリット・デメリットについて詳しく解説していきます。

7. RESTのメリット

REST APIには以下のようなメリットがあります。

• シンプルで実装や利用が容易
• 言語やプラットフォームに依存しない
• キャッシュが活用しやすい
• スケーラビリティの高さ
• 情報が豊富

7-1. シンプルで実装や利用が容易

REST APIは、HTTPプロトコルに基づき、GET、POST、PUT、DELETEなどの標準メソッドを活用するため、シンプルで直感的な設計が可能になります。GraphQLよりも学習コストが低く、特別なライブラリやツールが不要であることから、初心者でも扱いやすいAPIです。

7-2. 言語やプラットフォームに依存しない

REST APIは、HTTP通信を基盤としたAPIであるため、特定のプログラミング言語やプラットフォームに依存せずに利用できます。さまざまな技術スタック間での連携がしやすいことから、開発の自由度や拡張性を高めやすいメリットがあります。

7-3. キャッシュが活用しやすい

キャッシュとは、データを一時的に保存して次回アクセス時に再利用する方法です。

REST APIは、HTTPキャッシュ機能を活用することで頻繁にアクセスされるデータをキャッシュできるため、パフォーマンスの向上やサーバー負荷の軽減に繋げられます。

7-4. スケーラビリティの高さ

REST APIは、ステートレスな設計であることが特徴で、過去の通信状態を保持しないため、各リクエストが独立して処理される仕組みになっています。

この仕組みにより、アクセスが増えた際にもサーバーを追加してパフォーマンスを維持しやすいというメリットがあります。

7-5. 情報が豊富

REST APIはGraphQLが登場する前から広く利用されている技術で、Webサービスやモバイルアプリケーション、IoTデバイスなどさまざまな分野で活用できます。

そのため、ドキュメントやサポートが充実しており、初心者から上級者まで多くの開発者にとって利用しやすいAPIです。

8. RESTのデメリット

次はREST APIのデメリットについても確認しておきましょう。

• データの過剰取得・不足の発生
• ステートフルな処理には不向き
• バージョン管理は必須

8-1. データの過剰取得・不足の発生

REST APIは、必要なデータだけが欲しい場合でも、使用しない不要なデータまで取得してしまう「オーバーフェッチ」が発生します。また、反対に必要なデータが不足して複数回のリクエストを送らなければならない「アンダーフェッチ」が発生するケースもあります。

つまり、REST APIはGraphQLよりもデータ取得の効率性が低く、通信量の増大やリソースの浪費に繋がることが課題の一つです。

8-2. ステートフルな処理には不向き

ステートフルな処理とは、サーバー側で過去のやり取りや状態を保持しながら処理を行う方式のことです。

REST APIはステートレス設計であるため、過去の情報を保持する必要があるシナリオには不向きです。例えば、長時間のセッション管理や連続的なトランザクション処理などにおいては、REST APIの利用は避けたほうが良いでしょう。

8-3. バージョン管理は必須

REST APIでは、仕様変更の際に互換性の問題が発生する可能性があるため、既存クライアントへ影響を与えないようバージョン管理が必要になります。仕様変更を重ねるほどバージョン管理が複雑化しやすいため、運用負荷の増加に繋がります。

9. GraphQLとRESTの違いを比較

ここまでGraphQLとREST APIのメリット・デメリットを解説してきましたが、両者の違いを明確に把握するために比較表で特徴を整理しました。

GraphQLとREST APIの特徴の違いを簡潔にまとめると、GraphQLは欲しい情報を自由に取得できる柔軟性に優れた仕組みであり、REST APIはシンプルで扱いやすいAPIだと言えます。

10. GraphQLとRESTではどちらを選ぶべき？

自社のプロジェクトにおいて、GraphQLとREST APIでどちらを採用すれば良いか悩むケースも多いでしょう。上記で両者の違いを解説してきましたが、それぞれ異なる特徴を持つため、プロジェクトの要件や規模などによって使い分けることが大切になります。

そのため、どちらを導入すれば良いか迷う場合は、まず自社の開発目的や用途、要件などを整理することから始めましょう。

自社にノウハウが少なく判断に迷う場合は、比較的導入難易度や学習コストが低いREST APIから始め、その後システムの拡大や複雑化に伴い、GraphQLの部分導入や完全移行を検討するという流れも選択肢として考えられます。実際の開発現場でもよくある流れであるため、事例などを参考にするのも良いでしょう。

11. GraphQLが適しているケース・プロジェクト

では実際にGraphQLはどのようなケース・プロジェクトで向いているのでしょうか。具体的には以下の通りです。

• 複雑な画面・ダッシュボードを持つアプリケーション
• モバイルアプリケーション
• 複数のデータソース・APIを統合したい場合
• フロントエンド主導で開発・改善したい場合

11-1. 複雑な画面・ダッシュボードを持つアプリケーション

まず、複雑なUIを持つアプリケーションにおいてGraphQLは最大限に効果を発揮します。SNSや多機能なダッシュボード、Eコマースサイトでは、多くの情報を1つの画面に表示する必要があります。例えば、SNSのフィードなら、投稿一覧やコメント、通知などのデータを1画面内で表示しなければなりません。

REST APIでは複数回のリクエストが必要になるケースが多いですが、GraphQLなら、一度のクエリで必要な情報を一括で取得できるため、データを効率よく呼び出せます。

11-2. モバイルアプリケーション

GraphQLはモバイルアプリケーションと相性が良い側面も持っています。

モバイルアプリケーションにおいては、不要なデータ通信を避け、ネットワークの最適化を図ることが重要になります。GraphQLなら、一度に必要な情報をまとめて取得できるため、オーバーフェッチやリクエスト回数を大幅に減らし、レスポンスの高速化や通信量削減に繋げられます。

11-3. 複数のデータソース・APIを統合したい場合

GraphQLは、複数のAPIを統合する必要があるプロジェクトにも向いています。マイクロサービス環境では、機能ごとにデータソースが分散されているため、フロントエンド側でのデータ取得が複雑化しやすい課題があります。

GraphQL Federationを利用することで、複数のAPIを単一のAPIとして統合できるため、マイクロサービス環境でも柔軟なデータ基盤を構築することが可能です。

11-4. フロントエンド主導で開発・改善したい場合

先ほど述べましたように、フロントエンド主導で開発・改善を進めたい場合にもGraphQLは適しています。例えば、要件変更・UI変更が頻繁なプロジェクトにおいて、GraphQLならバックエンドの改修を待つことなくフロントエンド側が必要なデータをクエリで指定できるため、バックエンド開発者の負担や調整コストを削減しつつ、UIを素早く改善することが可能です。

12. GraphQLが適していないケース・プロジェクト

次にGraphQLが適していないケース・プロジェクトについて把握しておきましょう。以下のケースではREST APIの採用が向いています。

• シンプルなCRUDアプリ： REST + OpenAPIで十分なケースがほとんど。GraphQLのスキーマ設計・リゾルバー実装のオーバーヘッドが費用対効果に合わない。
• パフォーマンスがクリティカルな用途： N+1問題はDataLoaderで緩和できるが、根本的にクエリの複雑さが読めないため、レイテンシの上限保証が難しい。REST的なエンドポイントをキャッシュする方が素直。
• チームがRESTに慣れていて学習コストを払えない段階： GraphQLはフロントとバックの協調設計が必要で、チーム全体の習熟が前提。中途半端な導入はスキーマ設計の負債になりやすい。
• マイクロサービス間の内部通信： gRPCやREST + HTTP/2の方が型安全かつ高速。GraphQL Federationはそれ自体が複雑なシステムになる。
• ファイルアップロード・バイナリデータ中心のAPI： GraphQLはテキスト（JSON）ベースなので、マルチパートを扱うのが不自然。
• 公開APIでドキュメント・バージョニングが重要な場合： REST + OpenAPIの方がエコシステム（Swagger UI, Postmanなど）が成熟していて、外部開発者への導線が作りやすい。

13. GraphQLが採用されている主なWebサービス例

GraphQLは実際にさまざまなサービスで採用されています。ここでは、GraphQLを採用しているWebサービスの例を紹介します。

• Netflix
• Airbnb
• 楽天

13-1. Netflix

Netflixは、1997年にアメリカで創業した企業で世界最大級の動画配信サービスを運営しています。3億2500万人を超えるユーザーに対して映画やドラマ、オリジナル作品など多彩な作品を配信しています。

Netflixは元々REST APIを利用していましたが、システムの規模が大きくなるにつれて、多数のデバイスへの最適化が求められました。そこでGraphQLを採用し、デバイスごとに必要なデータを柔軟に取得する仕組みを構築することで、REST APIで発生していたオーバーフェッチ・アンダーフェッチの課題を解消したのです。また、フロントエンドとバックエンドの連携が強化され、複雑化されたシステムの運用・管理をシンプルにしています。

13-2. Airbnb

Airbnbは、2008年にアメリカで設立された企業で世界最大級の民泊マッチングプラットフォームを運営しています。さまざまな宿泊施設が登録されており、誰でも簡単に利用できるサービスです。

AirbnbはREST APIの利用において、UIの高速化に対して課題を感じていました。そこでGraphQLを導入し、複数のAPIリクエストを1つのクエリにまとめることで通信効率の改善に成功しました。それによりユーザー体験価値が向上し、快適に利用できるサービスへと成長しています。

13-3. 楽天

楽天は、1997年に創業された日本を代表するインターネットサービス企業です。ECモールの楽天市場をはじめ、デジタルコンテンツ、通信などさまざまな事業を展開しています。

楽天もGraphQLを採用しており、複数のサービス間でのデータ統合をシンプルにすることでモバイルアプリのパフォーマンス向上や開発効率の向上などのメリットを享受しています。

NetflixやAirbnb、楽天のGraphQL活用事例を見てわかる通り、さまざまなサービス・プラットフォームでGraphQLの適用が可能であることがわかります。

14. GitLabというプロダクトにおけるGraphQL活用のメリットとユースケース

GitLabは、ソフトウェア開発のライフサイクルを単一のプラットフォームで一元管理できるプラットフォームです。

GitLabでのGraphQLの実装例という観点で、特徴やユースケースを解説します。また、それによるGitLabのサービス全体の強みも紹介します。

14-1. GitLab GraphQL APIの特徴・ユースケース

GitLabにはプラットフォーム内にプロジェクトの基本情報やIssue、CI/CDパイプラインなどソフトウェア開発におけるさまざまなデータが蓄積・管理されています。GitLab GraphQLを利用することで、これらの複雑なデータを効率よく取得できます。

例えば、GraphQLによる柔軟なデータ取得はGitLabで以下のようなことを可能にします。

• イシューボードの特定
• プロジェクトのブランチルールをリスト表示
• 特定のユーザーグループに対する監査レポートの作成
• GitLab Duoデータの取得・エクスポート など

GitLab GraphQL APIは、目的に応じて利用することで開発効率の向上に役立てられます。また、GitLabにはREST APIも含まれているため、要件によって使い分けるのも良いでしょう。

14-2. GitLabの統合プラットフォーム・サービスとしての強み

GitLabは、AIによるソースコード管理や脆弱性管理、プロジェクト管理、CI/CDなどソフトウェア開発に必要な機能を単一のプラットフォームで利用できるため、開発効率の向上やコストの削減に繋げられます。

また、クラウド型・オンプレミス型の利用形態から選べるため、自社の環境に応じた導入が可能です。

GitLabが提供する豊富な機能を基盤として、GraphQL APIも積極的に活用することでGitLabの価値をさらに最大化し、迅速かつ高品質なソフトウェア開発を実現できるでしょう。無料トライアルもご用意しているので、DevSecOpsを支援するツールをお探しの方はぜひご検討下さい。

15. GraphQLの今後の動向

GraphQLは2015年公開された比較的新しい技術ですが、NetflixやAirbnbなどさまざまな企業で採用されるなど、REST API特有の課題解決のために広く使われています。近年のソフトウェア開発の規模の拡大や複雑化に伴い、今後も世界中の多くの企業でGraphQLの導入が進んでいくと考えられます。

ただ、REST APIならではのメリットを活かした開発が求められることも多いため、今後REST APIへのニーズが完全になくなるとは考えにくいでしょう。GraphQLとREST APIの両者の特性を活かしたハイブリッドアプローチなど、要件や目的に応じてそれぞれの技術を使いこなす考えが重要です。

また、GraphQL Federationにも注目が集まっているため、自社でノウハウを蓄積しておくことで開発アプローチの選択肢がさらに広がるでしょう。

16. GraphQLに関するよくある質問

最後にGraphQLに関するよくある質問を紹介します。GraphQLとREST APIの違いや、学習コストなどについて整理しておきましょう。

16-1. GraphQLはRESTより優れている？

GraphQLがREST APIより優れているわけではなく、両者の技術にはそれぞれ特有のメリットがあります。一言で説明するとGraphQLはデータ取得の柔軟性、REST APIはシンプルな扱いが可能であるというメリットを持っています。

そのため、「どちらが優れているか？」という視点ではなく、「自社の開発要件や規模に応じてどちらのアプローチが最適か？」という考えで導入判断を行うことが大切です。適切な選択を行うためにも、事前にGraphQLとREST APIのそれぞれの特徴をよく理解しておきましょう。

16-2. GraphQL導入前・運用時に評価すべきポイントは？

GraphQL導入前・運用時に評価すべき主なポイントをまとめると以下の通りです。

• GraphQLがプロジェクト要件や課題解決の手段としてマッチしているか
• GraphQLに関するノウハウの有無とチームの学習コストはどうか
• 運用時の負担はどうか など

これらの要素をもとに自社でのGraphQL導入可否を正確に判断・評価することが大切です。

16-3. GraphQLは初心者でも扱える？

REST APIよりも学習コストが高く、概念やクエリ言語、スキーマ定義など学習すべき内容は多いですが、基本的な仕組みを理解すれば初心者でも十分扱えると言えます。

自社でGraphQLを扱えるメンバーがいない場合は、学習環境を整えつつ段階的な導入をおすすめします。

GitLabではGraphQLが整備されているため、積極的な活用を通してGraphQLによるデータ取得例について理解することができるでしょう。

まとめ GraphQL導入は自社の要件を考慮して判断しよう

GraphQLは、クエリによる柔軟なデータ操作が可能な技術で大規模開発やモバイルアプリケーション開発などのシーンにおいてその価値を最大限に発揮できます。REST APIとよく比較されることが多いですが、導入判断時にはどちらが優れているかということではなく、自社の要件を十分に考慮しながら最適な選択を行う必要があります。

今回の事例で紹介したようにさまざまなWebサービスで利用できる技術であるため、自社の課題解決に繋がるケースでは積極的に導入していくと良いでしょう。

上で述べましたように、DevSecOpsプラットフォームのGitLabではGraphQLが整備されており、ツール内の複雑なデータを効率的に取得して開発効率の向上に役立てることができます。GraphQLを活用して、より高度な DevSecOps の実現を促進したい企業はぜひお気軽にお問い合わせ下さい。

お問い合わせはこちら

監修：小松原 つかさ @tkomatsubara （GitLab合同会社 ソリューションアーキテクト本部 シニアソリューションアーキテクト）