AWS Certified Generative AI Developer – Professional（AIP-C01）に合格したので振り返る

感想

取得順。

初回のスコアは701、そこから少し間が空き764でギリギリ合格。。！

正直なところ、2回目は少しプレッシャーがありました。

ただ、これまでの試験とは少し毛色が違っていて、新鮮味がありました。

例えば、MLAでは、どのようにモデルを最適化するか、どのような機械学習モデルを選択するか、といった「モデルそのもの」に関する知識が問われました。

一方でAIPは、出来上がったモデルをどのように評価するか、どのようにCI/CDを組むか、コンテンツの安全性をどのように担保するか、RAGやAgentをどのように組み込むか、といった、生成AIアプリケーションの設計・開発・運用に関する考え方が問われる試験だと感じました。

単純に「このサービスは何ができるか」を覚えるだけではなく、「この要件なら、どのような構成にするのが自然なのか」を考える必要があります。

普段から生成AIにはお世話になっていますが、その裏側で、実際にはこうした仕組みで設計・運用されているんだな〜と、なかなか興味深かったです。

意識したこと

2回目の受験に向けて特に意識したのは、「設問からぼんやりと設計パターンが思い浮かぶこと」です(当たり前ですが)。

AWS認定資格をいくつか取ったことがある方なら分かるかと思いますが、AWSの問題は独特のクセがあり、前提知識が無くても消去法でなんとなく解くことができます。

つまり、AIP固有の知識を知っていなくても、以下のように選択肢を絞ることができます。

問題文を読む
↓
目的・制約はなんとなく理解
↓
「何のパターンか」が浮かばない
↓
選択肢を上から読む
↓
消去法
↓
回答

しかし、これだと、選択肢を全て読む必要があり、時間が足りなくなります。

そのため、以下のような状態がより好ましいです。

問題文
↓
設計パターンを想起
↓
「これは○○の問題」
↓
選択肢と照合
↓
回答

とくに問題文から設計パターンを想起する部分が重要だと考え、私はその過程を「設計トリガー」と呼んでいました。

つまり、「こうきたらこう」ということです。

例えば、以下のように、問題文からシグナルを受け取り、それをトリガーに設計パターンが想起されるようなイメージです。

「何を今更、、」となるかもですが、改めて重要だと思ったので書き残しておきます。

以下に、AIと壁打ちした時の記録を加工し、そのまま貼り付けてみます。

間違っている内容があるかと思いますので、あくまで、”考え方の型” として参考になれば幸いです。

以下、AIとのやりとりを整理

問題文を読んだら、まず「何が設計を決める条件になっているのか」を探すようにしました。

例えば、「最新の情報を参照したい」「社内文書を根拠に回答したい」「複数のツールを使って処理したい」「回答の安全性を担保したい」といった記述です。

こうした条件を見つけたら、そこから必要な仕組みを考えます。

要件
 ↓
設計トリガー
 ↓
仮説
 ↓
アーキテクチャ
 ↓
AWSサービス

自分の中では、この「設計を方向付ける条件」を「設計トリガー」と呼んでいました。

問題文の「シグナル」を拾う

今回の学習で一番意識するようになったのが、問題文の中にあるシグナルです。

AIPの問題文は長いものも多いですが、設計判断を左右する情報は、その中の一部です。

例えば、

企業は社内文書を利用して従業員の質問に回答する生成AIアプリケーションを構築している。文書は毎日更新される。モデルを再学習することなく、最新情報を回答に反映する必要がある。

これを普通に読むと長いですが、設計者として読むなら、

社内文書
＋
質問応答
＋
毎日更新
＋
再学習したくない

くらいを拾えばいい。

すると、

「あ、これはRAGだ」

と設計パターンが浮かんできます。

これが今回、自分が意識していた**「シグナル → パターン想起」**です。

RAG / Knowledge Bases

例えば、以下のような記述が出てきたら、RAGを疑います。

• 最新情報を回答したい
• 社内文書を参照したい
• 頻繁にデータが更新される
• モデルを再学習したくない
• 独自データを使って回答したい
• 回答の根拠を持たせたい
• hallucinationを抑えたい
• 文書検索を行いたい

頭の中では、ざっくり以下のような構造です。

外部知識
    ↓
  検索
    ↓
関連情報を取得
    ↓
  Prompt
    ↓
   LLM
    ↓
  回答

つまり、

「モデルに知識を覚えさせる」のではなく、「回答時に知識を取りに行く」

という設計です。

ここからAWSのサービスに落とすと、Amazon Bedrock Knowledge Basesなどが候補になります。

ただし、ここで重要なのは、RAGとKnowledge Basesは同じものではないということです。

RAGは設計パターンで、Knowledge BasesはAWSでRAGを実装するためのマネージドサービスの一つです。

このように、まず設計パターンを考えて、その後にAWSサービスへ落とすようにしていました。

Agent / Action Group

RAGと混同しやすいのがAgentです。

例えば、問題文に以下のようなシグナルがあれば、Agentを疑います。

• AIが外部システムを操作する
• APIを呼び出す
• データベースを更新する
• 注文を作成する
• 予約する
• Lambdaを実行する
• 複数ステップのタスクを処理する
• ツールを選択して実行する
• ある程度自律的に処理する

例えば、

顧客から問い合わせを受けたら、注文情報を確認し、在庫を確認し、必要なら返品処理を行う。

これは単なるRAGではありません。

ユーザー
   ↓
 Agent
   ↓
注文情報を確認
   ↓
   API
   ↓
在庫を確認
   ↓
   API
   ↓
返品処理
   ↓
外部システム

つまり、

「情報を読む」のではなく「何かをする」

という要件が、Agentを選択する強いシグナルになります。

さらにAWS固有の知識として、Bedrock AgentがLambdaなどを利用して外部システムに対するアクションを実行する場合、Action Groupが候補になります。

Guardrails

Guardrailsは、モデルの能力を上げるための仕組みではなく、モデルの入出力を制御するための仕組みとして考えると整理しやすくなりました。

例えば、

• 有害なコンテンツを防ぎたい
• PIIなどの機密情報を扱う
• 特定のトピックへの回答を拒否したい
• 不適切な回答をブロックしたい
• 入力や出力を制御したい
• Responsible AIを考慮したい

といったシグナルです。

User
 ↓
Input
 ↓
Guardrails
 ↓
Model
 ↓
Output
 ↓
Guardrails
 ↓
User

ここで、例えば「回答の正確性を上げたい」という要件だけなら、必ずしもGuardrailsではありません。

一方で、「特定のトピックへの回答を禁止したい」「有害なコンテンツをブロックしたい」といった要件なら、Guardrailsのシグナルが強くなります。

つまり、

品質向上 ≠ Guardrails

であり、

ポリシーや安全性による制御 → Guardrails

と考えるようにしました。

Fine-tuningとRAGの切り分け

ここもAIPでは重要でした。

最新の情報を使わせたい
        ↓
       RAG

モデルの振る舞いや特定タスクへの適応をしたい
        ↓
    Fine-tuning

つまり、

「外部知識を参照させたい」のか、「モデルそのものを適応させたい」のか

を切り分けます。

「独自データがある」というだけでFine-tuningを選ぶのではなく、そのデータを何のために使うのかを見るようにしました。

Embedding / Vector Search

RAGをさらに掘っていくと、EmbeddingやVector Searchといった技術要素が出てきます。

問題文に、

• 文書をベクトル化する
• semantic similarity
• 意味的に近い文書を検索する
• similarity search
• vector database
• embedding model

などが出てきたら、Embedding → Vector Searchを疑います。

文章
 ↓
Embedding Model
 ↓
Vector
 ↓
Vector Store
 ↓
Similarity Search

これはRAGの内部構成要素として登場することもあります。

RAG
├─ Embedding
├─ Vector Search
├─ Retrieval
└─ Generation

このように、サービス名だけではなく、設計パターン → 構成要素という階層で整理すると覚えやすくなりました。

EvaluationとMonitoring

「AIの品質を確認する」という話が出てきたときは、EvaluationとMonitoringを分けて考えます。

Evaluation

• モデルの品質を測定したい
• 複数モデルを比較したい
• accuracy / correctness / relevanceを評価したい
• hallucinationを評価したい
• benchmarkを実施したい
• evaluation datasetを使いたい

つまり、

「モデルやアプリケーションがちゃんと動いているか、品質を測る」

という話です。

Monitoring

一方で、Monitoringは、

「本番環境で継続的に状態を監視する」

という話。

この2つは似ていますが、責務が違います。

コストとレイテンシ

ここは、単純なサービス暗記ではなくトレードオフの問題として考えるようにしました。

例えば、

• コストを削減したい
• 大量のリクエストを処理したい
• 低レイテンシが必要
• 高スループットが必要
• リアルタイム性が求められる
• token consumptionを削減したい

といったシグナルです。

この場合、必ずしも「一番性能の高いモデル」が正解とは限りません。

性能・精度
   ↑
   │       大型モデル
   │
   │   中型モデル
   │
   │ 小型モデル
   └──────────→ コスト

「要件を満たしつつ最もコスト効率の高い構成」と書いてあるなら、性能最大化ではなく、制約付きの最適化問題として読むようにしました。

Agentic Workflow

Agent単体よりも、さらに複数の処理を組み合わせるケースもあります。

例えば、

ユーザーの依頼を分析し、必要な情報を検索し、結果を検証し、別のシステムに登録する。

といった要件です。

Task
 ↓
Plan
 ↓
Retrieve
 ↓
Tool
 ↓
Analyze
 ↓
Tool
 ↓
Validate
 ↓
Response

ここでは、ざっくり、

RAG = 情報を取得する
Agent = ツールを利用して行動する
Agentic Workflow = 複数の処理を組み合わせてタスクを遂行する

というレイヤーで考えると整理しやすくなりました。

「設計トリガー」を単語帳で終わらせない

ここまで整理すると、例えば、

最新情報 → RAG
外部API → Agent
安全性 → Guardrails

という単語帳を作りたくなります。

ただ、実際の試験問題はそこまで単純ではありません。

例えば、

社内文書を検索して最新情報を取得し、その結果を基にAgentが外部システムを操作する。

という問題なら、複数の設計パターンが同時に登場します。

User
 ↓
Agent
 ├── Knowledge Base
 │      ↓
 │     RAG
 │
 └── Action Group
        ↓
    External API

そのため、最終的には「シグナル辞書」ではなく、設計グラフとして頭の中に持つことが重要だと感じました。

問題文
   ↓
シグナル
   ↓
設計パターン
   ↓
AWSサービス
   ↓
アーキテクチャ

問題文から複数のシグナルを拾い、それらを組み合わせた結果として、自然にアーキテクチャの候補が浮かんでくる状態を目指します。

最終的に目指した状態

今回の学習を通して、目指していたのは「AIPの知識量を増やすこと」だけではありませんでした。

問題文を読んだ瞬間に、設計空間が立ち上がる状態です。

例えば、

「最新の社内情報を回答に利用したい」
        ↓
「外部知識のRetrievalが必要」
        ↓
「RAGが候補」
        ↓
「Knowledge Basesなどを検討」

という接続が、ある程度自動的に出てくるようにする。

そうすると、4つの選択肢を一つずつ眺めながら「どれだっけ？」と考えるのではなく、問題文から立てた仮説と選択肢を照合できるようになります。

個人的には、今回のAIPで一番大きかった学びがここでした。

知識を増やすだけではなく、知識同士の接続を作る。

そのために、問題文のシグナルを拾い、設計トリガーとして整理し、そこから設計パターンやAWSサービスにつなげていく。

これが、今回自分なりにたどり着いたAIPの勉強方法でした。