「エーアイ」をバズワードにしないために RPA 導入経験と Kiro 上での Claude モデル利用経験から

Transcript

1. Claude Meetup Osaka (October 19, 2026) 「エーアイ」をバズワードにしないために RPA 導入経験と Kiro 上での Claude モデル利 用経験から Speaker : @kazzpapa3(ICHINO Kazuaki)
2. Biography { "Bio": { "Name": "ICHINO Kazuaki a.k.a. kazzpapa3", "Organization": "A certain AWS partner company", "Role": "Technical Support Engineer", "Favorite AWS Services": [ "AWS CLI", "AWS CloudTrail", "Kiro CLI" ], "Less Favorite AWS Service (as a Support Engineer)": [ "AWS Billing (請求ロジックが難解すぎる)" ], "Personal Interest": "初音ミク", "Socials": { "Twitter/X": "@kazzpapa3", "LinkedIn": "https://www.linkedin.com/in/kazzpapa3/" } } }
3. Who ? 何をしている人 ? @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 3 / 21
4. AWS のパートナー企業でテクサポをやっています お客様 － 弊社 － Amazon Web Services（AWS）という関係性で AWS アカウントをお客様へ再販しています 契約関係上、お客様は AWS への直接的なパスを持たないので、弊社が 代わりにサポート窓口を設け、AWS になりかわって技術サポートを行 います お客様からの問い合わせに対して、「公式ドキュメントで仕様が公開さ れているか」「発生事象の再現性があるか」を確認し、AWS に聞くし かない、となった時点で AWS Support に問い合わせをしています @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 4 / 21
5. 生成 AI の登場により AWS は割とドキュメントが整理されているので、ググリ力があれば、 サポート対応はなんとかなっていた ただし、英語が唯一の最新情報で正確な点はあり、難易度は高め さらに、ドキュメントがしっかりしているとはいえ、膨大すぎる 探しきれずに AWS Support に頼って、公式回答でドキュメント の提示があり、「くそー、ドキュメントあったんかー」という思い もしばしば ただ、生成 AI の登場や MCP の登場により、公式情報の検索は圧倒的 にやりやすくなりました @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 5 / 21
6. 主に利用している AI サービス @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 6 / 21
7. Kiro 一択、それも CLI 版での利用 AWS が提供する Kiro エージェント（の CLI 版） AWS CLI という、CLI ベースで AWS を操作可能な機能が好きで、タ ーミナルから基本的に離れたくないので愛用しています AWS 公式の MCP でドキュメントを検索しつつ、壁打ち、必要があれ ば AWS CLI を用いてアカウント内部の調査、検証環境構築のためのパ ラメータ抽出、のようなことが ターミナルから離れずにシームレスに 行える利便性 が高く、Kiro CLI を中心に据えています 作成した成果物を網羅的、多角的にレビューが必要な場合に Claude Code や Claude Cowork を利用しています @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 7 / 21
8. 主な Kiro CLI の活用事例 @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 8 / 21
9. お客様の AWS 環境の調査にも利用しています 昨今、アクセスキーなどクレデンシャル情報の流出が多発しています アクセスキー ＝ AWS をプログラムから利用するための ID とパスワ ードに相当するもので、API キーのような存在です AWS から届く緊急の通知に最初に触れるのが我々の部門なので、全 件、私の部署を通ります お客様へ通知しつつ、初動調査を行いリスク判断をして、お客様や社内 担当者への温度感調整や緊急閉塞をしますが、最近ここに AI が役立っ ています @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 9 / 21
10. ReadOnly のロールを用いて自律調査を実施 AWS が提供する Kiro CLI を用いて、カスタムエージェントを作成 以下のような指示を出し、リスク評価（利用料の高騰の観点、情報流出 や他者攻撃への加担など全般的な観点）と深刻度のレポートを依頼して います AWS アカウント ID 123456789012 で以下のような AWS 通知を受領した。リスク評価して ${recieved_announce} <Enter> @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 10 / 21
11. 元々、私たちが使う権限は極小化していた サポートに必要な権限のみ付与されていて閲覧だけに限定している そのため AI が暴走しても影響は少ない 弊社の踏み台アカウント お客様のアカウント 役割ごとの IAM グループ サインイン AssumeRole AssumeRole できる IAM ロ ールを厳格に定義している ReadOnlyAccess、 AWSSupportAccess という権 限だけ付与されている 「見るだけ」「AWS Support 」 に問い合わせるだけ AWS の設計でガードレールを敷くことができているため、一定程度信 頼してカスタムエージェント化 @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 11 / 21
12. カスタムエージェントの内容 # 指示項目 内容 1 役割 AWS リセールパートナーのテクニカルサポートエンジニアとして、AWS からの緊急通知を分析し、リ スク評価と顧客向け文面を作成する 2 事象の分類 通知を Abuse / Credential Exposure / SES Reputation / Trust & Safety / Billing Anomaly / Other の 6 カテゴリに振り分ける 環境調査 3 （任意） 専用の踏み台アカウント経由で、所定のプロファイルから対象顧客アカウントへ読み取り専用ロールで AssumeRole し、事象別の観点で調査する 作成・更新・削除やデータ持ち出しは禁止 4 リスク評価 「利用料の不正高騰 > リソース改変・削除 > レピュテーション低下」の重み付けで 3 軸評価し、 Critical / High / Medium / Low を判定する（Credential Exposure は原則 Critical） 5 成果物の出 事象分類・リスク評価・調査結果・推奨アクション・対応期限を定型フォーマットで提示し、返答期限 力 の明示と、迷う場合は保守的（高リスク側）に判断することを徹底する @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 12 / 21
13. ただ、ここまでの流れはやや保守的に進めた @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 13 / 21
14. どこまで自律的にやらせようか？という悩み 先ほどの自律的な調査も、裏でやっていることは以下のようなもの AWS CloudTrail という AWS アカウント内部での API 操作履歴を記 録するサービスで 履歴の洗い出し 洗い出した操作履歴を AWS 通知で問題視しているユーザー操作を起 点に数珠繋ぎに 時系列に沿って確認 する やろうと思えば自力でもできるし、元の運用に戻せる ただ CloudTrail というサービスが複数条件での検索がやりにくく、 抽出結果の視認性も悪め そのため補助ツールは作ったりしていた research-via-cloudtrail @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 14 / 21
15. なぜ、保守的に進めたか @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 15 / 21
16. 確実性や、べき等性の観点 前職で RPA（Robotic Process Automation）導入支援をしていたこ とがありますが、作成したロボットが シェルスクリプト（バッチファ イル）を上から順に実行するだけ、に落ち着いた例がありました ブラウザ操作などの GUI 操作に難があり、確実性を求めた結果、プ ログラムで実現すると確実性が上がる場合にそちらを採用することが 多くあった 結果、バッチファイルを叩くだけのロボットが出来上がった 「プログラマーでなくとも業務の自動化ができる」という触れ込みに対 して、アンチテーゼのような納品になったことは、笑い話のようでもあ り悩ましい現実だと振り返ったりします 16 / 21
17. AI では "確率論をどう信じるか" の負荷が高い RPA では手順を人間が教えてあげる必要があったのに対し、その部分も 自分で考えてくれる （と、期待値を持っている人は多いはず） 自律的にやってくれるなら「人間が楽になりそう」「人がやる業務を AI に置き換えられそう」という期待が少し過剰に見えています 触ってみると良い結果を得るにはそれなりの工夫が必要だし、信頼に足 る出力が得られているかのチェックに労力がかかることがわかります 使った経験の有無で認識に差が生まれると感じており、経営者の方や 上司にあたる方が率先して使ってくれていると話が通じやすい印象 （反対に RPA の頃よりもはるかに期待値・妄想が強い印象） @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 17 / 21
18. 製品やモデルへのロックイン問題 今後 AI はなくならず、人間と AI の協業で物事が成立する構図は続い ていくとは考えています ただ、個人的に、今の生成 AI や LLM 製品は "採算度外視" で提供して もらえている感覚 があります そして、ベンダーがまともにマネタイズし始めた時に、"高額すぎて手 が出せない" 製品になっていたらどうしよう、という感覚もあります そのため Claude Cowork でプレゼン資料や報告書の作成まではやら ず、集計を「素材にしやすくするツール」程度で留め、自分が理解でき る言語のツール化で留めておく、のような感じで利用しています @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 18 / 21
19. まとめ @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 19 / 21
20. たいした話でなく、結論もありませんが 結局、確率論でのアウトプットであるものに対してどこまで任せるか 自分の手元から AI を取り上げられた時にまごつかず、元の運用に戻せ るか 組み立てる部分や評価は人間がやるので、情報収集や整理をお願いす る、なおかつ、べき等性のあるシェルスクリプト作成をしてもらい、基 本はそちらを使うのようにアクセルを踏みすぎずに向き合っています 今日ご参加のみなさまで同じような悩みをお持ちの方、うちはこのよう に考えて乗り越えたよ、などあればこの後の時間でディスカッションで きると幸いです @kazzpapa3 / #ClaudeCommunity #ClaudeCommunityOsaka #asibinaa 20 / 21
21. Share your Lessons. Thank you.