penguin-claude-platform で開発を始めるための
環境構築・開発フロー・Git の基礎知識
GitHub と Claude のアカウントを準備し、
開発ツールを入れて
接続する手順。
p.3 - 8
自分で開発して internal で試し、
本番反映のときだけ
hori に承認をもらう流れ。
p.9 - 17
Git・GitHub・CI の仕組みと
Cloudflare の構成を
図解でやさしく。
p.18 - 25
GitHub と Claude Code を接続して
開発に必要な最低限のツールを揃える
コードを保管・共有するサービス
アカウント作成
github.com/signup で
アカウントを作る
堀之内に招待を依頼
作成した GitHub の
ユーザー名を堀之内に伝える
招待メールを承認
GitHub から届くメールの
Accept invitation を押せば完了
AI で開発を進めるツール
アプリをダウンロード
claude.ai/download から
Mac 版をインストール
会社のメアドでログイン
penguintrade.co.jp のメアドで
ログインすると Team プランに自動参加
Claude アプリには3つのモードがあり、サイドバー上部のボタンで切り替えます。頼みたい仕事に合わせて選びましょう。
質問・相談はここ
調べ物や相談をする場所。用語やエラーの意味、頼み方の相談など、なんでも日本語で質問できます。
例 「PR ってなに？」／「このエラーはどういう意味？」
デスクワークはここ
PC 上のデスクワークを任せる場所。手元のファイルやフォルダを直接読み書きして、集計や資料づくりを進めてくれます。
例 Excel の集計 ／ 資料・レポートの作成 ／ ファイルの整理
システム開発はここ
システム開発をする場所。リポジトリにつないでコードを書きます。この資料で説明する開発はすべて Code で行います。
例 業務アプリの開発 ／ Skill の作成 ／ 修正・機能追加
どのモードも使い方は同じで、日本語で話しかけるだけ。迷ったらまずチャットで相談し、作業を任せるときに Cowork / Code に切り替えます。
Claude アプリの Code モードを開いて、日本語で指示するだけで開発できる。
こんにちは、penguinさん
Chat の右にある </> で Code モードに切り替わる
こんにちは！何かお手伝いできることはありますか？
左下が「ローカル」であることを確認して、「こんにちは」など何でも送ればセッション開始
右上の >_ ボタンを押すとターミナルが開く。ここにコマンドを貼り付けて開発ツールを入れる。
Git が入っていないと画面上部に赤字で警告が出る。そのまま UI から Git をダウンロードでき、アプリを開き直せば認識される。
Git をインストール
この操作には Git が必要です。今すぐダウンロードしますか？
ダウンロード後、次のどちらかで Git を読み込む:
✓ 赤い警告が消えれば完了
作業フォルダを選び、GitHub のリポジトリを接続する。以降このフォルダに開発コードが溜まる。
こんにちは
左下のフォルダ名を押すと
フォルダ選択画面が開く
新規フォルダ
新規フォルダの名前:
適当な場所に新しいフォルダを作成
（ここに今後コードが溜まる）
このフォルダで https://github.com/
hori0926/penguin-claude-platform
を繋いでgitのセットアップしてください。
Claude が自動でセットアップ実行
開発からデプロイまでの流れと
承認が必要になるタイミングについて
コードを書いて、みんなで共有して、サーバーに置くまでの3ステップ。Claude Code が手元の開発を代わりにやってくれます。
Claude Code にコードを書かせ、手元の localhost で動作確認。思った通りに動くまで何度でも修正できます。
Claude Code
コード作成
localhost
検証・テスト
コードを GitHub に push し、PR（プルリクエスト）を作成。メンバーが確認・レビューして、問題なければ main にマージ。
GitHub
コード保存・PR
マージで自動反映
CI で検証・デプロイ
開発サーバー
*.internal.workers.dev
社内で動作を確認する用
本番サーバー
penguintrade.app
顧客が使う想定
開発サーバーと本番サーバーは独立。開発中は開発サーバーだけ使い、動作が確認できたら本番に反映。堀之内の承認が必要。
代表的なパターンは3つ。ほとんどの業務システムはこの組み合わせでできています。
バラバラの Excel や台帳をひとつのデータベースにまとめ、複数人が同時に閲覧・入力できるようにする。
例 在庫管理 ／ 顧客リスト ／ 査定履歴の一元管理
すでに使っているサービスと自動でデータをやり取りし、二重入力や手作業のコピペをなくす。
例 Google カレンダー連携 ／ CSV の取り込み・書き出し ／ LINE WORKS への通知
社外向けの紹介ページから社内向けの管理画面まで、ブラウザで開ける画面を作る。
例 LP（紹介ページ）／ 申込フォーム ／ ダッシュボード
ここに挙げたのは代表例です。迷ったら「こういうことはできる？」とまず Claude に聞いてみてください。
雛形があるので、シンプルなものなら30分ほどで「手元で動く」ところまでいけます。最初の題材におすすめの3つ。
Excel で管理している備品リストを Web 化。一覧・検索と、誰がいつ借りたかの記録ができる。
💬 頼み方
「備品を管理するアプリを作って。名前・置き場所・貸出中かどうかを記録したい」
入力フォーム1枚＋一覧画面。送信内容は自動でデータベースに貯まり、あとから検索・CSV 書き出しできる。
💬 頼み方
「店舗からのヒヤリハット報告フォームを作って。日付・店舗・内容を入力して一覧で見たい」
画面のない「仕組みだけ」のアプリ。決まった時刻に自動で動き、LINE WORKS にメッセージを届ける。
💬 頼み方
「毎朝9時に、今日が期限のタスク一覧を LINE WORKS に通知する仕組みを作って」
どれも既にある仕組み（アプリ雛形・データベース・LINE WORKS 通知）だけで作れます。リポジトリ内の既存アプリ（在庫管理・予算実績・シフトなど）のコードも Claude が参考にしてくれます。
ウェブシステムを作るほどではない定型業務は、Claude に手順を覚えさせて自動化できます。
月次の集計 ／ スプレッドシートへの転記 ／ 決まった形式のレポート作成 など、「画面はいらないが手間はかかる」仕事
マネーフォワードやスプレッドシートと接続し、チャットから直接データを見る・操作する。
💬「先月の交際費を科目別に集計して」
うまくいった手順を Skill として登録。次からは一言で同じ手順が正確に再現され、配布すれば全社員が使える。
💬「/月次集計 を実行して」だけで完了
決まった日時に自動実行されるよう登録すれば、人がやっていた定型業務そのものをなくせる。
event_repeat 毎月1日の朝、自動でレポートが届く
進め方は段階的で OK。まず①で試し、繰り返す業務になったら②で Skill 化、手順が完全に固まったら③でルーティン化します。
internal（社内確認用）環境までは自分で完結できる。本番デプロイのみ堀之内の承認が必要。
本番に影響しない作業用ブランチで
Claude Code にコードを書かせる
変更内容を main に取り込むための
申請を出す（Claude が自動作成）
自動テスト通過後、自分で承認して
main に変更を反映する
マージと同時に開発サーバーへ自動反映
自分でアクセスして動作を確認する
開発サーバーで問題なければ堀之内に連絡
ここだけ承認が必要
1つの機能を作るときの基本ステップ。この繰り返しで開発が進みます。
「○○の一覧を表示して、
検索もできるようにして」
のように日本語で OK
💬 例:
「在庫の CSV をアップロードしたら自動で DB に入るようにして」
Claude Code がコードを書き、
「できました」と報告してくる
✺ 「CSV アップロード機能を実装しました。localhost:8787 で確認できます」
ブラウザでlocalhost を開いて
実際に動かして確認する
check_circle 思った通りに動く？
cancel 違ったら Claude に修正を依頼
「PR 作って」と頼むだけ。
マージすると開発サーバーに
自動で反映される
💬 「OKなので PR 作って」
→ Claude が PR 作成 → マージ → 公開
STEP 1〜3 は 何度でも繰り返し OK。納得いくまで修正してから STEP 4 に進んでください。
機能ごとにチャットを分け、完成したら「開発サーバーに入れて」で公開フローへ進む。
開発の段階に応じて 3 つの環境を順番に使う。データは環境ごとに完全に分離されている。
使い方
自分の PC 上でコードを書きながら
動作を確認する。他の人や環境には
一切影響しないため、自由に変更や
修正を繰り返すことができる。
使い方
LINE 連携などローカルでは動かせない
機能がサーバー上で正しく動くか確認する。
他のメンバーの PC からもアクセスできる
ため、チームでの動作確認にも使う。
使い方
お客様が実際の業務で使用する環境。
デバッグや動作検証は行わない。
本番への反映は堀之内が実施するため、
準備ができたらご連絡ください。
Git・GitHub・CI の仕組みと
Cloudflare の構成について
名前は似ているが、それぞれ役割が異なる。以下の図のような包含関係になっている。
GitHub 上で自動処理を実行する仕組み。PR を出すと自動テスト、マージすると自動デプロイ。
Git のデータをクラウドに保存して、みんなで共有する場所。PR やレビューもここ。
ファイルの変更履歴を記録するツール。変更日時・作業者・変更内容がすべて記録される。
任意の時点の状態に戻すことも可能。Git がなければ GitHub も Actions も使えない。
プロジェクトのコード・設定ファイル・変更履歴をまとめて保管する場所。
共有フォルダに似ているが、「誰がいつ何を変えたか」がすべて記録される点が異なる。
GitHub に置くことでチーム全員が同じコードにアクセスでき、過去の任意の時点に戻すこともできる。
うちでは penguin-claude-platform という1つのリポジトリに全アプリをまとめて管理している（モノレポ方式）。
ファイルの変更を「いつ・誰が・何を変えたか」のセットで記録する操作。
ゲームのセーブポイントに近く、いつでも過去の状態に戻せる。
上の画面は過去のコミット一覧で、1行が1回の保存に相当する。
コミットメッセージ（タイトル部分）には変更の要約を書く。
うちでは Claude Code に「コミットして」と言うだけで、差分の要約・コミット実行まで自動で行われる。
本番（main）から分岐して作る作業用コピー。本番に影響を与えず開発でき、完成したら main に合流（マージ）させる。
ブランチで作った変更をmain に取り込む「申請」のこと。
「このコードを本番に反映していいですか？」というリクエストで、変更差分・変更理由・CI チェック結果がひとまとめに記録される。
上の画面は PR 一覧で、各行が1つの申請に対応する。
CI（後述）が通れば自分でマージ（=main に合流）できる。
うちでは Claude Code に「PR 出して」と言えば、タイトル・本文の作成から GitHub への投稿まで自動で行われる。
PR を出すと自動で走る「品質チェック」の仕組み。
GitHub Actions というサービスが、lint（コードの書き方ルール違反がないか）・typecheck（型の整合性に矛盾がないか）・build（アプリが正しくビルドできるか）の3つを順に実行する。
すべて通過（緑チェック）しないとマージできない。
人間が目視で確認する代わりに機械が自動判定するので、うっかりミスの混入を防げる。
失敗した場合は Claude Code に「CI 直して」と言えば、エラー内容を読み取って自動修正してくれる。
Cloudflare = 現在使用しているサーバー管理サービス。開発用・本番用でサーバーもデータベースも別々に存在する。
コードの置き場所
マージで
自動反映
堀之内が
承認して反映
Worker
コードが動くサーバー
D1
データベース
環境変数
APIキー等の秘密情報
Worker
コードが動くサーバー
D1
データベース
環境変数
APIキー等の秘密情報
gh, wrangler, Claude Code を
インストールし GitHub に接続する。
開発 → PR → マージ → 動作確認。
承認不要で繰り返し実行できる。
internal で動作確認が取れたら
堀之内に承認を依頼する。
不明点は Claude Code に質問できる。解決しない場合は堀之内（hori0926）に連絡する。