必要なもの: メールアドレス、ロールを作成するための管理者権限 (または十分な IAM 権限) を持つ AWS アカウント、エージェントが返す内容を読むための数分間。
30 秒で覚える構文
エージェントには平易な言葉で話しかけてください。基本的なパターンは次のとおりです。@agent— 担当エージェント:@alex（クラウド）、@oliver（セキュリティ）、@tony（データベース）、@kai（Kubernetes）、@anna（調整）。#tool（省略可能） — 出力の種類:#dashboard、#report、#recommend、#alert、#chart、#kb。- リクエスト内容 — 必要なことを自分の言葉で記述します。文脈情報はインラインで追記できます。
登録する
app.cloudthinker.io でサインアップします。
- 名前、業務用メールアドレス、パスワードを入力する
- 受信トレイに届いた確認リンクをクリックする
- プロフィールを確認する
AWS を接続する
Settings → Connections → New Connection → AWS に移動し、認証方法を選択します:
IAM ロールの方法では、CloudThinker が信頼ポリシーに貼り付ける External ID と、アタッチする 最小権限 を表示します。AWS Console での完全なウォークスルー — CloudShell コマンドと信頼ポリシーの JSON を含む — は AWS 接続ガイド にあります。デフォルトで安全: 推奨されるスターターポリシーは読み取り専用です。書き込み操作 (適正サイズ化、インスタンス終了、セキュリティグループの変更) には別のポリシーが必要であり、承認ワークフロー のもとで実行されます — 最初の実行でエージェントがあなたの承認なしに変更を適用することはありません。成功状態: 接続カードが緑のドット付きの Connected に変わります。ディスカバリーが自動的に開始され、約 2 分以内にカードにゼロ以外のリソース数 (インスタンス、RDS、S3 など) が表示されます。ディスカバリーがゼロのままの場合は、下の トラブルシューティング をご確認ください。
| 方法 | 使用する場面 | 必要なもの |
|---|---|---|
| IAM ロール (推奨) | 本番アカウント。長期的なキーより安全 | 作成するロールへの信頼ポリシー + アクセス許可ポリシー |
| アクセスキー | クイックデモまたはサンドボックスアカウント | プログラムによるアクセスを持つ IAM ユーザー。アクセスキー ID + シークレット |
ディスカバリーを確認する
左サイドバーの Infrastructure タブを開きます。以下が表示されているはずです:
- ゼロ以外のリソース数を持つリージョンのリスト
- EC2 インスタンス、S3 バケット、RDS データベース、Lambda 関数のうち少なくとも一つ
- サービスの関係を示すトポロジービュー (グラフアイコンをクリック)
最初のプロンプトを実行する
New chat をクリックして以下を貼り付けます:Alex が CloudWatch の使用率メトリクスを照会し、リソースインベントリと結合して、構造化されたサマリーを返します。期待される出力: 約 30 秒以内に以下を含むレスポンスが届きます:
- リソース数 — リージョン別の EC2、RDS、S3、Lambda など
- アイドル候補 — 過去 30 日間で CPU 使用率が
<20%に維持されたインスタンス - 節約見込み額 — アイドルリソースへの支払いを続けた場合の月間コスト
- インライン推論 — 「過去 30 日間の CloudWatch の
CPUUtilizationメトリクスを確認し、95 パーセンタイルが 20% を下回るインスタンスをフィルタリングしました」
完了の確認
- Infrastructure タブで AWS リソース数を確認でき、実態と一致している
-
@alexが実際に認識できるインスタンスやサービスを名指ししたサマリーを返した - Alex がアイドルリソースを見つけるために何をしたか、チームメンバーにインライン推論を読んで説明できる
トラブルシューティング
AWS 接続が「Pending」または「Failed」のままになる
AWS 接続が「Pending」または「Failed」のままになる
考えられる原因: 信頼ポリシーに External ID がない、またはロールのアクセス許可ポリシーが狭すぎる。確認事項:
- AWS Console → IAM → Roles → 対象のロール → Trust relationships で、
sts:ExternalIdの条件が CloudThinker に表示されたものと完全に一致しているか確認します (余分なスペースがないか)。 - ロールのアクセス許可ポリシーに最低限
ec2:Describe*、rds:Describe*、s3:List*、cloudwatch:GetMetricStatisticsが含まれているか確認します。完全なリスト: AWS 接続の最小権限。 - ロールの max-session-duration が 1 時間以上であるか確認します。
接続済みだがリソース数がゼロのまま
接続済みだがリソース数がゼロのまま
考えられる原因: ロールは引き受けられるが、アカウントが実際に使用しているリージョン / サービスに対して
Describe 権限がない、またはアカウントが有効化されていないリージョンにある。確認事項:- Connection details → Discovery log に移動します。試行された各リージョンの結果が表示されます。
AccessDeniedエラーが、拒否された API 呼び出しを正確に示します。 - アカウントにロールが見えるリージョンに少なくとも 1 つのリソースが実際にあるか確認します。
Alex が「I don't have access to AWS yet」と言う
Alex が「I don't have access to AWS yet」と言う
考えられる原因: 接続が現在のワークスペースにバインドされていません。各接続は 1 つのワークスペースに属しており、別のワークスペースでチャットしている可能性があります。修正: ワークスペースセレクター (サイドバーの上部) が AWS を追加したワークスペースと同じを示しているか確認します。ワークスペースを切り替えるか、チャット中のワークスペースで接続を再追加します。
最初のプロンプトが自分のデータではなく一般的なベストプラクティスを返す
最初のプロンプトが自分のデータではなく一般的なベストプラクティスを返す
考えられる原因: Alex がツール (CloudWatch、Cost Explorer) にアクセスできなかった — 通常は権限の不足。具体的なデータが利用できない場合、一般的な回答がフォールバックとして返されます。確認事項: Alex の返答の一番下までスクロールします。Tools used セクションに試みたすべての API 呼び出しと成否が表示されます。失敗した呼び出しには AWS エラーが表示されます。修正: ロールに不足している権限を追加し (CloudWatch 読み取りは使用率向け、Cost Explorer 読み取りは費用向け)、再接続してからプロンプトを再実行します。
最初のプロンプトのレスポンスが遅い、またはタイムアウトする
最初のプロンプトのレスポンスが遅い、またはタイムアウトする
考えられる原因: 初期ディスカバリーがまだ実行中 — Alex はインベントリが完了するまで待ってから推論します。その後のプロンプトははるかに速くなります。修正: Infrastructure タブにゼロ以外のリソース数が表示されるまで待ち、プロンプトを再実行します。ディスカバリーは通常、500 リソース未満のアカウントで 2〜5 分で完了します。
次のステップ
ロール別 AgenticOps クイックウィン
自分のロールを選び、プロンプトをコピーして、1 分以内に実際の結果を得る
さらにツールを接続する
Datadog、GitHub、Kubernetes、Postgres、Slack を追加 — 接続が増えるにつれてエージェントが有効化されます
チームを招待する
Owner、Admin、Developer、Viewer ロールでチームメンバーを追加し、ワークスペースアクセスを割り当てます
プランをアップグレードする
チームの準備ができたらシートを追加してトライアルからアップグレード — シートごとの課金、いつでもアップグレード可能