はじめに
JAWS-UG東京 2026秋 〜AWSライトニングトークNight〜に参加しました。
私はAWS若手LT大会(2026/10/19)で、AndroidアプリのAPIキーをLambdaで隠しても入口は公開のままであり、使用量プランで被害を限定する、という内容を発表しました。
話すこと
- 聞いたLT2本の内容(スライドの記載に基づく部分)
- 社会人1年目で、AndroidアプリのAPIキーの問題に取り組んだ私の立場から、それをどう受け取ったか(私の解釈)
話さないこと
- 他のLTの内容
当日はオンライン配信・録画がありませんでした。そのため本記事では、スライドの記載に基づく部分と私の解釈を分けて書きます。
イベント概要
| 項目 | 内容 |
|---|---|
| イベント名 | JAWS-UG東京 2026秋 〜AWSライトニングトークNight〜 |
| 開催日 | 2026年10月21日(水)19:00〜21:00 |
| 会場 | TSUNAGU BASE(高輪ゲートウェイ) |
| 形式 | オフライン(オンライン配信・録画なし) |
| ハッシュタグ | #JAWSUG_Tokyo |
全体
参加の目的は、AWS技術や知識を学ぶことと、AWSが好きな方と交流することでした。参加者は熱意のある方が多く、発表内容も多岐にわたっていました。AWSに特化した話だけでなく、IT技術全般の発表もあり、AWSの知識が浅い方でも楽しめる内容でした。
その中で私自身の学習内容や業務と紐づく以下2本が特に印象に残ったため、ここに記録します。
- 城前りりかさん「Cognitoで学ぶ認証認可入門」
- みのるんさん「Kiro Crewで『みのるん式』仕事術やってみた」
1. Cognitoで学ぶ認証認可入門
まず初めに、現在、生成AIが普及してバイブコーディングなどが広まり、セキュリティ意識が低くなりがちです。セキュリティ問題も頻繁に起きている今の時代に、セキュリティの根幹である認証・認可の発表を聞けたため、自分事として受け止められました。
合わせて、私が前回のLT大会で発表した「APKからAPIキーが読めてしまう」という問題点に近い内容でした。その発表でも述べたとおり、秘密が漏れる前提で、被害を限定する設計が必要です。Cognitoの話は、同じ「秘密を持てないクライアント」という前提に対する、別の問いへの答えに見えました。
聞いた内容(スライドより)
- 認証は「あなたは誰か」、認可は「何をして良いか」
- OIDCはOAuth 2.0を基盤にした認証プロトコルで、エンドユーザー、RP(認証を要求するアプリ)、OP(ユーザーを認証してIDトークンを発行するプロバイダー)が登場する。今回はOPにCognitoを採用
- Cognitoのユーザープールは主に認証、IDプールは主に認可を担い、AWS認証情報を生成する
- 認可コードフローでは、ログイン後、ブラウザには本物のトークンではなく認可コードを渡す。その後、ブラウザを介さない別の通信で、コードをトークンに交換する
- このフローはクライアントシークレットを安全に保存できるアプリに向く。ただしPKCEを使えば、パブリッククライアントでも認可コードフローを使える
私の解釈
私のAndroidアプリは、OAuthの用語ではパブリッククライアントに当たります。配布されたAPKからキーを取り出せるため、クライアントに秘密を安全に保存できません。PKCEを使えばこうしたパブリッククライアントでも認可コードフローを使えると解釈しました。
ここで、私が扱った問題との違いを整理します。
- 私のAPIキーは認証ではなく、使用量プランで呼び出しを計量するための識別子です。盗まれる前提で、被害の上限を決める設計にしました。
- PKCEは、認可コードの横取りを防ぐ仕組みです。アプリが本物かを証明するものではなく、被害を限定する仕組みでもありません。
つまり、PKCEは私の問題を直接解決するものではなく、別の問いに対する答えだと理解しました。ただし、ログインを導入すればユーザー単位で識別でき、ユーザーごとの制限や遮断が可能になると考えました。
2. Kiro Crewで「みのるん式」仕事術やってみた
聞いた内容(スライドより)
- みのるん式のポイントは3つ
- 何でもAIに相談する癖をつける
- 「半自動化」から入ってサイクルを作る
- モノレポで「コンテキストの複利」を生かす
- 確認なしで任せる分、安全装置としてのガードレールが重要
- ガードレールには強弱がある
- 弱い:会話で伝えた約束、CLAUDE.mdなどの設定ファイル
- 強い:パーミッションやフックによる機械的な強制
- 送信・申請・削除の直前では、確定ボタンは人間が押す
- 破られては困る禁止事項は、お願いではなく設定で強制する
私の解釈
AIを使うと、短時間でかなりの量のアウトプットが出てきます。これまで人間が目で確認していた作業でも、量が増えた分、全部に目を通すのは難しいと実感しています。かといって、確認せずにAIへ全部任せると、重大なミスがあっても気づけません。
そこで効いてくるのが、2番目のポイントの「半自動化から入る」だと受け取りました。人間が確認する場所を意図的に残しておけば、見落としの範囲を限定できます。そのサイクルが回り始めてから、確認なしで任せる部分にガードレールを足していく、という順序だと理解しました。
私は社会人1年目で、今は基礎を学ぶことを優先し、AIに任せる範囲を意図的に絞っています。ただ、今後任せる範囲が広がれば、確認しきれない部分が必ず出てきます。そのときは、今回の「お願いではなく設定で強制する」という話を思い出し、ガードレールを意識して設計したいです。
まとめ
- パブリッククライアントでは、クライアントに秘密を置けない前提で設計(Cognito LT)
- 「お願い」は強制ではない。禁止事項は設定で強制(みのるん式LT)