Claude Codeで作ったアプリを安全に公開する/Built with Claude Japan 2026

2026.11.7 BUILT WITH CLAUDE JAPAN 2026 (ハッカソン)において講演した内容です。

Transcript

1. BUILT WITH CLAUDE JAPAN 2026 Claude Codeで作ったアプリを 安全に公開する リポジトリと実行環境を公開するための共通対策 AGENDA 01 リポジトリ公開 設定・履歴 02 アプリ公開（リリース） 実行環境・Claude Security 株式会社ジェネラティブエージェンツ 取締役 Claude Community Ambassador 吉田 真吾 手元で資料を見ながらどうぞ ※本セッション内容は個人の見解であり、Anthropicの公式見解や推奨を示すものではありません。 ※セキュリティ対策において『これさえやっておけば絶対にOK』という銀の弾丸はありません。 docs.google.com/presentation/d/18XRC XqFoJFpVLoltO9XacNA4dP9RMmA8ClEk 3B2LUhU 01
2. BUILT WITH CLAUDE JAPAN 2026 吉田 真吾 Yoshida Shingo 株式会社ジェネラティブエージェンツ 取締役COO / Co-founder AWS Serverless Hero Claude Community Ambassador サーバーレス技術の普及とAIエージェント開発を推進。 Claude Community(JP), Serverless Community(JP) ・LangChain Community (JP) などを主宰。 主な著書 『実践Claude Code入門』 『LangChainとLangGraphによるRAG・AIエージェント［実践］入門』 『ChatGPT/LangChainによるチャットシステム構築［実践］入門』 『AWS生成AIアプリ構築実践ガイド』 『AWSによるサーバーレスアーキテクチャ（監修）』ほか多数 02
3. BUILT WITH CLAUDE JAPAN 2026 バイブコーディング実践入門（AIコーディング道場） アイデアから実装・レビュー・公開までを体験するための教材 GitHub リポジトリ 公開教材サイト https://github.com/AI-Eng-Dojo/getting-started-vibecoding https://ai-eng-dojo.github.io/getting-started-vibecoding/ 03
4. BUILT WITH CLAUDE JAPAN 2026 Built with Claude: Japan 2026 •Anthropic × Cerebral Valley •オンライン｜日本全国から参加 •11月2日開幕 ／ 最終提出 11月8日(日)20:00 JST •キーワード • 一人の深い知見から生まれるもの。 • 人々が手を携えて、壁を取り払うもの。 04
5. BUILT WITH CLAUDE JAPAN 2026 ハッカソンの提出要件 最終提出締切 デモ動画 公開リポジトリ 対象範囲 11月8日(日) 3分以内 public化 期間中の開発分 20:00 JST 日本語・動く様子を中心に 【今日のメイン】 期間中に作った機能・コー ド 公開リポジトリ≠アプリ公開 動作URLやインターネットへのデプロイは必須ではないが、Artifactやアプリを公開するほうがよりよいことが想定されます 本日：公開リポジトリを安全に出すための要点解説 ＋オプション：READMEの書き方、動作URLに本番公開する前の準備 提出先：cerebralvalley.ai/e/built-with-claude-japan2026/hackathon/submit 05
6. BUILT WITH CLAUDE JAPAN 2026 チェックリスト 0 READMEを整える （推奨） 3 リポジトリ(GitHub)の 設定を確認する 1 公開ファイルにAPI キーなどが混入して ないか確認する 4 仕様やコードを点検 する （Claude Security） 2 Gitの履歴にも混入し てないか確認する 5 最終チェック 動かして確認する 06
7. CHECK 00 ｜ READMEを整える（推奨） 0 READMEを整える 記載すべき内容 良いREADMEの書き方（参考） ・アプリ名 GitHub Docs：About READMEs ・概要 Make a README ・解くべき課題 Open Source Guides ・主要な機能 ・使った技術や動作に必要な環境 ・セットアップ方法や実行手順 ・デモ動画へのリンク など 07
8. CHECK 0 ｜ READMEを整える（推奨） ｜ 0 READMEを書かせる このリポジトリの実態に基づいて、提出・公開する作品のREADMEを作ってください。 まず、既存のREADME、公開可能なソース、依存関係・ビルド設定、実在する画像、既存のテストと文書を確認してください。.env、秘密鍵、認証 情報、顧客データなどの秘密値を含むファイルは読み込まず、秘密値を回答・ログ・画像に出さないでください。不明な点は推測せず、要確認事項 にしてください。 既存の本人編集や言語構成を保持し、正式なアプリ名、誰の何の課題を解くか、実装済みの主な機能、使った技術や動作に必要な環境、セットアッ プと実行手順、実在するデモ動画リンクを整理してください。未実装の機能や、未確認のURL・バージョン・ライセンス・動作結果を創作しないで ください。動画がなければ準備中としてください。 README.mdを英語、README-ja.mdを日本語にする場合は、両版の項目と意味を揃え、相互の言語リンクを付けてください。既存の日本語版が README.ja.mdなど別名なら、勝手に改名せず既存名を使ってください。英語版と日本語版を用意すること自体はイベントの必須条件ではありませ ん。 実在するロゴ画像があれば、HTMLで中央配置し、その下に正式なアプリ名と短い説明を置く案を示してください。画像がなければ存在するように 装わず、文字だけにしてください。画像の相対リンクと日本語版へのリンクが実在するかを確認してください。 APIキー等の秘密値をREADMEにもソースにも書かず、必要な項目名だけを定義し値を空にした.env.exampleを案内してください。READMEへ環境変 数の名前や設定方法を列挙する必要はありません。 コマンドは既存の設定や文書に根拠のあるものだけを記載し、確認した根拠と未実行を区別してください。依存の導入、コマンド実行、外部API利 用、認証、ファイル変更、commit／push／公開はまだ行わず、最初はREADME案と根拠・不足情報を提示してください。 08
9. CHECK 01 ｜ 公開ファイルにAPIキーなどが混入してないか確認する 1 公開ファイルにAPIキーなどが混入してないか確認する 公開可能 公開禁止、ダメ絶対 ・仕様書、設計書 ・APIキーが記載された環境変数ファイル(.env) ・ソースコード ・秘密鍵・認証ファイル ・環境変数の設定例・テンプレ ・ユーザーの実データ (.env.example) ※画像・ノートブック内の出力も確認する ・ダミーデータ コーディングしていると、公開してよいものと、公開したくないものが混ざってくる スクリーンショットやノートブックも、実行結果の出力に実データや秘密の値が写っていないか確認する 09
10. CHECK 01 ｜ 公開ファイルにAPIキーなどが混入してないか確認する 1 環境変数ファイル(.env)とは？ ソースに直接書くと、コードの共有やcommitと一緒に公開されてしまう 環境変数 開発環境 → コード（プログラム） SERVICE_API_KEYという名前で環境変数から値を読む SERVICE_API_KEY ＝ 開発用の値 値そのものはコードに書かれてないので、コードを 本番環境 → 共有・commitしても問題ない SERVICE_API_KEY ＝ 本番用の値 環境変数に注入したい値を定義しておくためのファイル 例：接続先URL・APIキー。多くの言語・フレームワークに、設定値とプログラムを分ける仕組みがある 10
11. CHECK 01 ｜ 公開ファイルにAPIキーなどが混入してないか確認する 環境変数ファイル(.env)を未追跡ファイル(除外設定)にする .gitignore の例 .envと派生を除外し、.env.exampleだけを共有する # ローカルの秘密設定を除外 設定例の値は空にする：SERVICE_API_KEY= .env 暗号化・既追跡ファイルの除外・履歴削除にはならない .env.* # 値が空の設定例だけ共有 !.env.example 11
12. CHECK 01 ｜ 公開ファイルにAPIキーなどが混入してないか確認する Claude Codeに点検を依頼する Gitコマンドを自分で実行するのに慣れてない場合は、次のようにClaude Codeへ依頼できます。Claude Securityのコマンドではなく、一般的な依頼 文の例です。特定のAPIキーの値そのものはClaude Codeに指定せず、ファイル名や追跡状態などから点検を始めるための書き方です。 このローカルリポジトリをpublicで提出する前に、公開対象へAPIキー等が混ざっていないか点検してください。 必要なGitの読み取り操作は選んでください。最初は本文や差分本文を開かず、追跡・未追跡・ステージ済みのファイル名と設定項目を確認してくださ い。 秘密ファイルや実値をモデル入力、回答、ログ、画像へ出さないでください。既存のローカル秘密検出ツールが使える場合は、値を伏せた出力になること を確認し、対象と実行案を先に示してください。使えなければ勝手に導入せず未確認としてください。 結果は、ファイルの場所と必要な行番号、情報の種類、影響、対処案、再確認方法を報告してください。値そのものや全文を貼らないでください。 .envと派生、認証ファイル、コードへの直書き、ログや添付物を候補に含め、.gitignoreだけで既追跡や履歴も解決したと判断しないでください。どの範囲 を確認でき、どこが未確認かも明示してください。 私の確認前に変更、キー失効、履歴書換え、commit、push、fetch等の外部通信、認証変更を行わないでください。安全を保証する回答にせず、過去履歴 は別の確認項目として残してください。 候補が出たら、場所・種類・対処を読んで人が判断します。ファイル名だけの確認を秘密の検査完了とはせず、値を出さないローカル検査と必要な 確認を組み合わせます。プロンプトだけでツールの権限や外部送信が制限されるわけではありません。 12
13. CHECK 01 ｜ 公開ファイルにAPIキーなどが混入してないか確認する 1 コミット前に止める pre-commitフックをしかける 1 pre-commitの準備（macOS/Homebrewの例） brew install pre-commit gitleaks pre-commit --version gitleaks version # .pre-commit-config.yaml repos: - repo: https://github.com/gitleaks/gitleaks rev: v8.30.1 hooks: - id: gitleaks-system pass_filenames: false 2 設定を追加 # .gitleaks.toml [extend] useDefault = true [[rules]] id = "workshop-dummy-marker" description = "Workshop dummy marker; not a real credential" regex = '''WORKSHOP_DUMMY_SECRET_[A-Z0-9]+''' 3 ダミーをステージ → 隔離環境で検出・失敗を確認 pre-commit install printf 'WORKSHOP_DUMMY_SECRET_123456\n' > hook-check.txt git add -- .pre-commit-config.yaml .gitleaks.toml \ hook-check.txt pre-commit run gitleaks-system 4 ダミー検出でcommit失敗を実測（隔離した練習repo） git commit -m "Check pre-commit hook" git rev-list --count --all 5 ダミー除去・再ステージ → 検査・commit成功を実測 printf 'No secret values in this file.\n' > hook-check.txt git add -- hook-check.txt pre-commit run gitleaks-system git commit -m "Add secret check" 公式資料：pre-commit ／ Gitleaks v8.30.1 フック定義 ／ Gitleaks 設定 ／ Git pre-commitフック ／ Homebrew pre-commit ／ Homebrew gitleaks 13
14. CHECK 02 ｜ Gitの履歴にも混入してないか確認する 2 Gitの履歴にも混入してないか確認する 開発中にAPIキーをコミットしてしまった。気づいて.envを削除し、削除した状態をコミットした。GitHubの最新ファイル一覧では.envが見えなくな るので、問題なさそうに見える。 コミット A コミット B GitHub 最新の一覧 APIキー入りの.envを追加 .envを削除してコミット .envは見えない → app.js .env app.js → app.js SERVICE_API_KEY=実キー ▲ 前のコミットに保存した内容は残る（履歴から取り出せる） 削除のコミットを追加しても、過去のコミットは消えない Gitは過去のコミットも保持している。最新の一覧に見えないことは、履歴にないことを意味しない 14
15. CHECK 02 ｜ Gitの履歴にも混入してないか確認する 2 APIキーが外部に露出したらすぐに失効させること！ 01 02 03 失効・ローテーション 再発行と確認 履歴修復 有効な実キーの公開が分かったら、 必要な再発行と設定更新、利用履歴 その後に、運営・共同作業者と調整 発行元で行う の確認を進める する ・リポジトリをprivate化しても、漏れたAPIキーの無効化には意味がない ・ファイル削除しただけでは、履歴からの消去にはならない 15
16. CHECK 02 ｜ Gitの履歴にも混入してないか確認する 2 履歴全体の点検をClaude Codeへ依頼する コミット前フックが見るステージ済みの変更と、既に保存されたGit履歴は別の対象です。フックを導入しても、過去のコミットに残る秘密を確認・解消 したことにはなりません。提出前には、過去の履歴も別の工程で点検します。 このリポジトリに、APIキー等が過去のGit履歴に残っていないか点検してください。 まず読み取りのみで、手元のブランチ、タグ、remote-tracking参照、shallow clone等の取得範囲を整理し、「全履歴」と呼べる対象と未取得・未確認の範囲を明示してく ださい。勝手にfetchや外部接続はしないでください。 実キー、個人情報、秘密を含むファイル本文や差分をモデル入力・回答・ログ・画像へ出さないでください。利用可能なツールで、値は伏せて報告だけを得る計画を示し てください。必要なツールが未導入なら勝手に導入せず、必要な準備と未確認範囲を報告してください。 必要な読み取り操作は選び、過去の全対象を検査してください。現在のファイルにないこと、特定の.envだけを調べたこと、コミット前フックの成功を、履歴全体に秘密 がない根拠にしないでください。 候補はコミットID、ファイルの場所、必要な行番号、秘密の種類、確認対象の範囲、影響と対処案を報告し、値自体は出さないでください。 有効な実キーの公開が分かった場合は、発行元での失効・ローテーション、必要な再発行と設定更新、利用履歴の確認を最優先として案内してください。 履歴修復は、提出要件、共同作業者への影響、バックアップと復旧方法、GitHubやfork・clone等の残存可能性を確認したうえでgit filter-repo等の案を提示してくださ い。キー失効、削除、履歴書換え、force push、本番設定変更は、私の明示確認前に実行しないでください。完全削除や安全を保証しないでください。 たとえばGitleaksを利用できる環境なら、gitモードの--redactと全参照を対象にする--log-optsの指定を確認します。ただし、手元にない履歴、GitHubのPull Request 参照やfork、Git管理外の画像・ログ等まで同時に検査できるとは限りません。既存ツールの有無と対象を先に確認し、今回のプロンプトも実行済みの結果ではない ことを区別します。 16
17. CHECK 03 ｜ リポジトリ(GitHub)の設定を確認する 3 リポジトリ(GitHub)の設定を確認する 確認する画面（リポジトリの Settings） 見るポイント 01 Settings → General 対象のリポジトリの可視性（public / private） 02 Settings → Collaborators / Teams コードを変更できる人や権限を最小限にする 03 Settings → Rules / Branches 提出ブランチの確認・保護・例外 04 Settings → Advanced Security シークレットの検出・push protectionの有効状態など GitHub Actionsを使ってる場合は、その権限やログも確認する 17
18. CHECK 04 ｜ 仕様やコードを点検する（Claude Security） 4 仕様やコードの脆弱性を検出するClaude Securityとは Claude Codeのセッション内で動く、マルチエージェントの脆弱性スキャン用プラグイン。リポジトリ全体、またはブランチ・Pull Request・コミッ トの差分を対象にできる。 01 構造を把握 → 02 → 脅威モデル化 03 脆弱性を探索 → 04 独立に検証 → 05 レポート出力 結果の出力 修正案（Suggest patches） 前提と注意 CLAUDE-SECURITY-<日時>/ に保存 別のエージェントがpatchを検証 使用量に計上・結果は都度変わりうる Markdown・JSONL・SARIF テストがあれば実行して確認 静的解析・依存関係の検査と併用 CWE分類・対象commitを記録 適用は人がgit applyで判断 既存ツールの置き換えではない 出典：Claude Code Docs「Scan your codebase for vulnerabilities」 18
19. CHECK 04 ｜ 仕様とコードを点検する ｜ 補足 4 Claude Securityでコードの脆弱性診断を実行する 1 導入して、メニューを開く # 公式マーケットプレイスから導入 /plugin install claude-security@claude-plugins-official # メニューを開く /claude-security 3 引数や自然文でも指定できる /claude-security scan my branch scan commit abc1234 fix finding F3 4 結果を読む 2 メニューで対象と処理を選ぶ Scan codebase 全体、または領域を絞ってスキャン 差分のみ ブランチ差分・PR・1コミット（コミット済み） Suggest patches 指摘を選んでpatchを作成（自動適用なし） CLAUDE-SECURITY-<timestamp>/ CLAUDE-SECURITY-RESULTS.md CLAUDE-SECURITY-RESULTS.sarif patches/F1.patch 5 patchは人が確認して適用する git apply CLAUDE-SECURITY-<timestamp>/patches/F1.patch 全体は作業ツリー（未コミットを含む）、差分はコミット済みの変更だけを見る 出典：Claude Code Docs「Scan your codebase for vulnerabilities」 19
20. CHECK 04 ｜ 仕様とコードを点検する ｜ 補足 4 プロンプトからも指示できる Claude Securityプラグインでこのアプリを点検してください。 公開する入口、実行環境、利用データ、信頼しない入力、守るべき認可と秘密の条件を整理し、対象範囲と 不足情報を示してください。 公式の/claude-securityから選ぶScan codebaseと変更スキャンの対象の違いを説明し、今回どの コードが対象になるかを確認してください。実在しないコマンドは作らないでください。 実行前に利用経路、必要条件、対象コード送信の許可と利用量の見込みを示し、私の確認まで実行しないで ください。秘密や個人情報の実値を回答やログへ出さないでください。 実レポートが得られたら、対象コードの識別情報、時刻、Coverage、指摘、未調査範囲を対応付けてくだ さい。 採用候補の指摘について、仕様との関係、コード上の経路、最小修正案、同じ条件での再現と正常系の確認 を提案してください。 未実施を指摘0件と扱わず、動的診断や本番環境の安全確認を実施したと推測しないでください。修正、 キー失効、履歴書き換え、外部送信は追加の確認前に行わないでください。 20
21. CHECK 04 ｜ 仕様やコードを点検する（Claude Security） 4 仕様レベルの不具合も検知される Claude Securityの検出例 ※ 本件は修正済みのため、掲載に問題ありません 何が起きるか 予定IDのMD5を48ビットに切り詰めたjob ID が衝突し、細工した招待で別の予約を乗っ取 れてしまう→仕様レベル 静的解析はまずこれが十分役立つ かなり混み入った仕様の脆弱性が検出できる 賢さ（卓越した手順＋モデルの賢さ） 21
22. CHECK 05 ｜ 動かして確認する 5 最後に、動かして自分自身で確認する コードの点検では静的なチェックのみ。実際に起動して実行してみると、ビルド結果・環境変数・応答内容など、コードを読むだけでは分からない ことが判明する可能性があるため やること 01 起動する 02 表示内容の確認 03 複数のユーザーで試 してみる READMEの手順どおりにローカル起動 OKの目安 手順どおりに起動でき、アプリの機能が実行で きた APIキーなどやばい情報がブラウザーにまで届かない 応答内容、エラー表示などが問題ない 自分・他人のデータ／ログイン・未ログイン／違った 他人のデータが見えない、意図通りの権限レベ ユーザー権限（役割）で同じ要求を送る ル（できること・できないこと） localhostなど、まずは自分が試してよい手元の環境で起動して確認を行う 22
23. CHECK 00–05 ｜ 提出前の最終判断 最後に、提出動画も見返す 有効なAPIキーが写り込んでないか？ 他人の実データが表示されてないか？ エラー画面に機密情報が露出していないか？ 23
24. BUILT WITH CLAUDE JAPAN 2026 【再掲】チェックリスト 0 READMEを整える （推奨） 3 リポジトリ(GitHub)の 設定を確認する 1 公開ファイルにAPI キーなどが混入して ないか確認する 4 仕様やコードを点検 する （Claude Security） 2 Gitの履歴にも混入し てないか確認する 5 最終チェック 動かして確認する 24