# AI時代における低レイヤーから理解するWebアプリケーション研修ガイダンス RubyでHTTPサーバからフレームワーク・ORM・CRUDアプリまでを作り、Webの仕組みを学ぶ教材です。講師付きの研修にも独学にも利用できます。完成コードの配布や自動採点はなく、各Phaseの課題・テスト・レビュー観点を使って自分の実装を確かめます。 [対象読者と前提知識](#対象読者と前提知識) · [学習時間](#学習時間の目安) · [開始手順](#最初に行うこと) · [進め方](#講師付き独学での進め方) · [対応環境](#前提環境とセットアップ) · [目次](#カリキュラムテキスト) ## 対象読者と前提知識 Webアプリの内部構造を理解したい方、Railsなどでの開発経験を土台から整理したい方を対象にします。Railsの経験は必須ではありませんが、プログラミングの初歩から学ぶ教材ではありません。 - **Ruby**: 条件分岐・繰り返し、配列・Hash、メソッド、クラス・インスタンス、ブロック、例外、`require`を使い、小さなスクリプトを自力で書いて実行できること。 - **ターミナル**: 作業ディレクトリの移動、ファイル作成、コマンド実行、エラー出力の確認、複数端末の利用、`Ctrl-C`でのプロセス停止ができること。 - **Git**: clone、status、diff、add、commitを使えること。自分たちの演習用リポジトリでの共同レビューではbranch・push・Pull Requestの操作も使いますが、独学はローカルのGitだけでも進められます。 - **学びながら身につける内容**: Socket・HTTP・TLS・Rack・SQL・ORM・テスト駆動開発（TDD）。専門知識は前提にしません。基本的なHTMLを読めるとViewの課題に取り組みやすくなります。 Rubyやターミナルの操作で止まる場合は、先に小さなRubyプログラムを実行し、変更をGitにコミットする練習をしてください。 ## 学習時間の目安 以下は学習計画を立てるための暫定的な見積もりで、受講実績に基づく標準時間ではありません。本文の読解・必須課題の実装・テスト・振り返りを含み、任意の発展課題と前提知識の補習は含みません。経験や調査にかかる時間に応じて調整してください。 | 区間 | 内容 | 目安 | | --- | --- | --- | | 準備 | 環境確認・作業領域作成 | 4〜6時間 | | Phase 1 | Socket・HTTPサーバ | 8〜12時間 | | Phase 2 | WEBrick読解 | 4〜6時間 | | Phase 3（3.1〜3.3） | Rack・並行処理・TLS | 16〜24時間 | | Phase 4（4.1〜4.7） | フレームワーク構築 | 24〜36時間 | | Phase 5（5.1〜5.9） | SQL・ORM | 24〜36時間 | | Phase 6（6.1） | CRUDアプリへの統合 | 12〜18時間 | | 最終課題 | 発表・自己評価・レビュー | 4〜6時間 | | **合計** | | **96〜144時間** | 週8時間なら12〜18週が計画の目安です。まずPhase 1まで進めて実際の所要時間を記録し、残りの計画を見直してください。 ## 最初に行うこと 1. 下の[安全上の注意](#安全上の注意教育用本番利用不可)と[前提環境](#前提環境とセットアップ)を読み、[セットアップガイドの手順1](./SETUP.md#1-必要なツールを用意する)でRuby・Bundler・Gitなどを用意します。 2. 次のコマンドで教材を取得し、教材ルートで環境を確認します。clone済みなら、そのディレクトリに移動して`bundle install`から実行します。教材自体を改変・再配布する場合は、[利用・改変について](./CONTRIBUTING.md)に従いfork先をcloneしてください。 ```console git clone https://github.com/speee/training-web-app.git cd training-web-app bundle install bundle exec rake test ``` `Markdown lint passed`、`Rack 3 compatibility checks passed`と、テストの失敗・エラーがないことを確認します。失敗した場合は[セットアップガイド](./SETUP.md)で依存ツールや実行環境を確認してください。 3. 教材ルートから演習用の作業領域を作ります。`work/`が既にある場合は作成コマンドを繰り返さず、既存の演習を続けてください。 ```console ruby script/prepare_exercise.rb work cd work bundle install bundle exec rake test git init git status --short ``` 最小テストが成功し、`coverage/index.html`が生成されれば準備完了です。生成物には完成したサーバやORMは含まれません。以後の実装・演習テストは`work/`内で行います。[Phase 1](./phase-1.md)を開いて、Step 0から始めてください。 ### 教材と演習コードの置き場所 | 場所 | 役割・保存するもの | | --- | --- | | 教材リポジトリのルート | README・各Phaseの説明・教材用の検証。ここに演習の実装を追加しません | | `work/`内の別Gitリポジトリ | 自作コード・テスト・自分の`Gemfile.lock`・設計メモ・提出物。Phaseをまたいで同じ実装を育てます | 教材側では`work/`をGit管理対象外にしています。教材ルートでコミットしても演習は保存されません。上の`git init`で`work/`を独立したリポジトリにし、`work/`内で差分を確認してコミットしてください。作業ディレクトリは別の場所でも構いません（[セットアップ手順3](./SETUP.md#3-演習用の作業領域を用意する)）。 成果をリモートにも保存する場合は、自分のアカウントに演習用リポジトリを作り、`work/`のremoteとして設定します。最初は非公開で構いません。本家教材へのPRを提出先にはしません。コミット・共有前には[成果物を共有するときの注意](#成果物を共有するときの注意)を確認してください。 ## 講師付き・独学での進め方 どちらも[目次](#カリキュラムテキスト)の順に進めます。各Phaseの冒頭で目的・前提・到達目標を読み、課題を実装し、テストと本文の確認方法で確かめます。提出物と設計メモを保存し、レビュー観点に答えられることを確認して次へ進みます。各ページの上下に「前へ・目次・次へ」のリンクがあります。 | 場面 | 講師付き研修 | 独学 | | --- | --- | --- | | 計画 | 講師と日程・必須範囲・提出先・レビュー担当を決める | 上の時間見積もりをもとに学習枠を決め、Phaseごとに実績を記録する | | 質問 | 講師が指定したチャットや面談で相談する | 公式ドキュメントと最小の再現コードで調べ、学習メモに仮説・結果を残す。相談相手がいれば、自分のリポジトリのIssueや学習コミュニティを利用する | | 提出 | 演習用リポジトリのPRと設計メモを、指定された提出先に共有する | Phaseごとのコミットとメモを保存する。GitHubを使う場合は自分のリポジトリのPRにまとめてもよい | | レビュー | 各Phaseのレビュー観点を使い、受講者同士・講師で確認する | 協力者に依頼するか、時間を空けて自分の差分・テスト・設計理由を読み直し、同じ観点で自己レビューする | | 最終課題 | ローカルデモ・発表・相互レビューを行う | ローカルデモを録画し、[最終課題](./goal.md)のルーブリックで自己評価とレビュー記録を残す | 質問には、該当Phase・目的・OS/Ruby/Gemの版・実行コマンド・期待結果・実際の結果・試したことを添えます。機密情報を除いた最小の例にすると、他の人も確認しやすくなります。 独学のレビュー記録には「観点／根拠となるコード・テスト／判定／改善点」を書き、未確認の項目は未確認と残します。相互レビューができない場合は自己レビューで代替したことを明記し、他者の評価として扱わないでください。AIは下の[利用ルール](#3-aiを前提にした学習設計重要)に従い、概念の説明や自分の説明の検証に使い、実装・解答の生成は依頼しません。 ### 成果物を共有するときの注意 公開する対象はコード・説明資料・録画などです。演習サーバは下記の安全上の注意に従い、自分のPCのループバックだけで起動してください。 公開リポジトリへのpushや資料の共有前に、コードだけでなくGitの履歴・DB・ログ・スクリーンショット・録画・スライドも見直し、個人情報、社内情報、実サービスの認証情報、トークン、秘密鍵を含めないでください。実名・メールアドレス・実データはダミーに置き換えます。秘密鍵のignore設定と、コミット済みの場合の対処は[セットアップガイド](./SETUP.md#証明書秘密鍵の取扱い)を参照してください。 ## 安全上の注意（教育用・本番利用不可） **本教材のコードと演習で作る成果物は教育用の最小構成です。本番利用はできません。信頼できないネットワークやインターネットへ公開しないでください。** 最終デモも自分のPC上で行います。 - HTTP・HTTPS・Rack・WEBrickのすべてを`127.0.0.1`（IPv6なら`::1`）のループバックに限定して待ち受けます。ホスト指定の省略や`0.0.0.0`・`::`での待受、公開トンネル、外部向けポート転送は使いません。 - 演習にはダミーデータを使い、個人情報・実サービスの認証情報を入れません。ループバックだけでも、ブラウザ経由の攻撃や同じPCの別プロセスからのアクセスをすべて防げるわけではありません。 - `key.pem`などの秘密鍵は共有・コミットしません。生成前のignore設定と確認手順は[証明書・秘密鍵の取扱い](./SETUP.md#証明書秘密鍵の取扱い)を参照してください。 - `curl -k` / `--insecure`は証明書の検証を無効にします。[ローカルの自己署名証明書演習](./phase-3-3.md)での比較にだけ使い、通常は`--cacert cert.pem`で検証します。 ### 各課題で確認する安全上の完了条件 | 学習項目 | 必須の確認と参照先 | | --- | --- | | パストラバーサル | [Phase 1のファイル一覧課題](./phase-1.md)に取り組む場合、指定ルート外へのアクセスを拒否するテストを通す | | XSS | [Phase 4.5](./phase-4-5.md)でERB出力のエスケープを学び、入力をHTMLとして実行させない | | CSRF | [Phase 6.1](./phase-6-1.md)で状態変更フォームを保護し、不正なリクエストでDBが変わらないことを確認する | | SQLインジェクション | [Phase 5.1](./phase-5-1.md)以降、値のバインドを必須にし、[Phase 5.5](./phase-5-5.md)で動的なカラム名も制限する | ### 最小実装に残る防御の不足 以下は教材全体として実装・検証を保証しない防御です。自分の成果物で実装済みか未実装かを記録し、既知の脆弱性と影響を[最終評価](./goal.md)で説明してください。 - 接続数・スレッド数・リクエスト行／ヘッダ／ボディ長の上限、メモリ・CPUの使用量制限 - 読み取り・書き込み・TLSハンドシェイクのタイムアウト、遅いクライアントへの対処 - 例外・切断時のソケットcloseやスレッド・DB接続の確実な回収（TLS例の`ensure`だけでは全経路を保証しない） - HTTP構文やメッセージ境界の厳密な検証、不正な入力の一貫した拒否 - 認証・認可、セッション管理、機密情報を漏らさないログ・エラー応答、依存ライブラリの継続的な更新 上記の課題やテストを通しても、本番利用・外部公開の安全性を保証するものではありません。[WEBrick公式README](https://github.com/ruby/webrick#readme)も用途をテストとローカル開発に限定しています。 ## 前提環境とセットアップ 最終検証日: **2026-09-02**（環境スモークテスト。演習の完成実装の検証ではありません） 本教材はRuby 4.0系・Rack 3系を基準にします。リポジトリでは動作確認の起点としてRuby 4.0.6（[.ruby-version](./.ruby-version)）とRack 3.2.7を指定しています。特にRack 3のインターフェース・ヘッダの規約を前提として読み進めてください。 その他のツールは、以下の用途を満たすものを使います。細かなリリース番号や導入方法を教材の必須条件にはしません。 - Bundler: RubyとGemの依存関係を管理する - rackup・WEBrick: Rackアプリの起動と既存サーバ実装の読解 - Rake・Minitest・SimpleCov: テストの実行、アサーション、カバレッジ計測 - SQLite3・sqlite3 Gem: ローカルDBへの接続、SQL実行、結果の取得 - Rubyのライブラリ: Socket、OpenSSL、ERB、JSONなど。対話環境のIRBはGemfileにも記載しています macOSやLinuxでの操作を例示しますが、OSを限定する趣旨ではありません。Windows・WSLなどを含め、コマンド、パス、パッケージ名、ライブラリの設定の違いは、利用環境のドキュメントを調べて読み替えることを期待します。未検証の組み合わせすべての動作を保証するものではありません。 動作確認の対象は、CIの**macOS 15・Ubuntu 24.04**で、リポジトリの`.ruby-version`・`Gemfile.lock`を使った環境スモークテストです。確認するのは依存APIやテスト環境の起動までで、学習者の完成実装や本番運用の動作保証ではありません。Windows・WSLや異なる依存関係の組み合わせはCIの検証対象外です。環境差の解消は[セットアップガイド](./SETUP.md#環境差に遭遇したら)を参考に、利用者側で行ってください。 [Gemfile](./Gemfile)は必要な依存関係の出発点です。[Gemfile.lock](./Gemfile.lock)は教材リポジトリの検証時の組み合わせを記録するもので、受講者全員に同じ版を要求するものではありません。自分の環境で依存関係を解決し、テストで確かめ、その結果を自分のlockfileに残してください。 [セットアップガイド](./SETUP.md)には必要な操作、確認すべき結果、各Phaseへの引き継ぎをまとめています。コマンドをそのまま再現することではなく、何を準備・確認しているか理解して進めてください。Webサーバ・自己署名証明書の例はローカル学習専用です。 ## 本研修について 本研修は、AI時代におけるエンジニアの本質的な価値を再定義し、 「コードを書く人」ではなく「システムを理解し、意思決定できる人」を育成することを目的としています。 近年、AIによるコード生成の発展により、開発の生産性は飛躍的に向上しました。 しかしその一方で、以下のような問題が顕在化しています。 - フレームワークの裏側を理解する機会の減少 - 技術選定や設計判断の経験不足 - 「なぜ動いているのか」を説明できない状態 - AIが生成したコードの品質を評価できない これらは一時的な問題ではなく、AIの進化とともに加速していく構造的な課題です。 --- ## 本研修の目的 本研修では、以下の状態を目指します。 ### 目標 - Webシステムの構成要素を自分の頭の中で再現できる - フレームワークの抽象化を剥がして理解できる - 技術選定・設計判断を説明責任をもって行える - AIの出力を「使う」のではなく「評価できる」状態になる --- ## 研修の基本思想 ### 1. 抽象を降りて、また登る 現代の開発は高い抽象レイヤー（Railsなど）から始まりますが、 本研修では意図的に逆のアプローチを取ります。 > **Socket → HTTP → Webサーバ → Rack → フレームワーク → アプリケーション** 一度低レイヤーに降りて理解した上で、再び抽象に戻ることで、 「理解した上で使う」状態を作ります。 --- ### 2. フレームワークを“読む側”になる Railsは非常に強力ですが、ブラックボックスとして使うだけでは限界があります。 本研修では： - WEBrickのコードを読む - Rackの仕様を理解する - フレームワーク的な仕組みを自作する ことで、**「作られたものを使う人」から「仕組みを理解する人」へ**シフトします。 --- ### 3. AIを前提にした学習設計（重要） 本研修ではAIの利用を**明確に制限・推奨の両面から設計**します。 AIは強力なツールですが、使い方を誤ると「理解の機会」を奪います。 本研修ではそのリスクを避けるため、以下のルールを採用します。 --- #### ❌ 禁止事項（最重要） 以下の用途でのAI利用は禁止します： - コードの生成（例：実装を丸ごと作らせる） - 課題の解答をそのまま出力させる - 自分で考えるべき設計や実装の代替 理由： > 本研修の目的は「仕組みを理解すること」であり、 > 実装プロセスそのものが学習の中心であるためです。 AIに実装を任せることは、この最も重要な学習機会を失うことを意味します。 --- #### ✅ 推奨事項（積極的に使う） 一方で、以下の用途ではAIを積極的に活用してください： ##### 1. コードリーディングの補助 - WEBrickのコードの解説 - Rackのインターフェースの意図の説明 - 処理フローの可視化 例： - 「このクラスは何を責務としているか？」 - 「このメソッド呼び出しの流れを図解して」 --- ##### 2. 概念理解の深化 - HTTPプロトコルの詳細 - ミドルウェアの設計思想 - フレームワークとライブラリの違い --- ##### 3. 比較・設計の思考補助 - 「この設計のトレードオフは何か？」 - 「別の実装方法はあるか？」 - 「Railsはなぜこの構造を採用しているのか？」 --- ##### 4. 自分の理解の検証 - 自分の説明をレビューさせる - 誤解していそうなポイントの指摘をさせる --- #### AIの正しい使い方（原則） 本研修におけるAIの位置づけは以下です： > ❌ 実装者ではない > ✅ 解説者・壁打ち相手である --- #### 判断基準（迷ったら） 以下の問いで判断してください： - 「これは自分で手を動かすべきか？」 - 「AIに任せると理解が浅くならないか？」 もし少しでも迷ったら、その作業は**自分でやるべき領域**です。 --- #### 期待する状態 このルールを守ることで、以下の状態を目指します： - コードを書いた理由を説明できる - 他人のコード（AI含む）を評価できる - 抽象と具体を行き来できる --- 本研修は「AIを使う訓練」ではなく、 > **「AI時代でも通用するエンジニアになる訓練」** です。 --- ## カリキュラム概要 ### Phase 1: 低レイヤー理解（HTTPサーバ） - Socketを使ったHTTPサーバ実装 - GETリクエストの処理 - HTTPプロトコルの理解 ### Phase 2: 既存実装の読解 - WEBrickのコードリーディング - 自作実装との差分理解 ### Phase 3: 抽象化の導入 - Rackの理解 - 自作HTTPサーバのRack対応 ### Phase 4: フレームワーク構築 - ルーティング - コントローラ - ビュー - ミドルウェア的な仕組み ### Phase 5: データ層の実装 - シンプルなO/Rマッパーの実装 - SQLとの対応関係の理解 - ConsoleモードによるORMの対話的な検証 ### Phase 6: 統合 - 自作コンポーネントを組み合わせたWebアプリ構築 - CRUDアプリケーションの実装 --- ## 最終成果物 以下をゴールとします： ### 1. 動作するWebアプリケーション - 自作HTTPサーバ or Rack対応サーバ - 自作フレームワーク要素 - 自作ORM - CRUD機能を持つアプリ ### 2. 技術プレゼンテーション 以下をスライドで発表： - どのような構成で実装したか - 各レイヤーの役割 - Railsとの違い - 学んだこと - 今後どう活かすか --- ## 評価観点 以下の観点で評価します： - 技術理解の深さ - 実装の一貫性 - 抽象化の適切さ - 説明能力 - トレードオフの理解 - 外部公開せずローカルで実演し、既知の脆弱性と未実装の防御を説明できること --- ## 受講にあたっての姿勢 ### 推奨する姿勢 - わからないことを放置しない - 「なぜ？」を繰り返す - 手を動かして検証する - 他人のコードを読む ### 非推奨な姿勢 - AIのコードをそのまま使う - 動けばよしとする - 深掘りせずに進む --- ## この研修で得られるもの この研修を通じて得られるのは、単なる技術知識ではありません。 - 抽象と具体を行き来する力 - システム全体を俯瞰する力 - 長期的な設計判断を行う力 - AI時代におけるエンジニアとしての軸 --- ## 最後に これからのエンジニアに求められるのは、 「コードを書く速度」ではなく「意思決定の質」です。 本研修はそのための土台を作るものです。 簡単ではありませんが、確実にあなたのエンジニアとしての価値を引き上げます。 主体的に取り組んでください。 ## カリキュラムテキスト * [Phase 1: 低レイヤー理解（HTTPサーバ実装）演習](./phase-1.md) * [Phase 2: 既存実装の読解（WEBrick）演習](./phase-2.md) * [Phase 3.1: 抽象化の導入（Rack）演習](./phase-3-1.md) * [Phase 3.2: サーバの並行性（スレッド対応HTTPサーバ）をTDDで安全に導入する](./phase-3-2.md) * [Phase 3.3: HTTPS対応（TLSの導入）演習](./phase-3-3.md) * [Phase 4.1: 素のRackアプリの限界を体験する](./phase-4-1.md) * [Phase 4.2: ルーティングをTDDで実装する](./phase-4-2.md) * [Phase 4.3: Controller / Action 構造をTDDで実装する](./phase-4-3.md) * [Phase 4.4: render / redirect をTDDで実装する](./phase-4-4.md) * [Phase 4.5: View / Template をTDDで導入する](./phase-4-5.md) * [Phase 4.6: Request / Params をTDDで整理する](./phase-4-6.md) * [Phase 4.7: 共通処理（before_action / Middleware的仕組み）をTDDで導入する](./phase-4-7.md) * [Phase 5.1: 生SQLのつらさをTDDで体験する](./phase-5-1.md) * [Phase 5.2: 1テーブル専用ModelをTDDで導入する](./phase-5-2.md) * [Phase 5.3: Consoleモードを実装する — 自作ORMを対話的に検証する](./phase-5-3.md) * [Phase 5.4: レコードをオブジェクトとして扱う（TDD）](./phase-5-4.md) * [Phase 5.5: Finder / Query をTDDで共通化する](./phase-5-5.md) * [Phase 5.6: 永続化（Create / Save / Update / Delete）をTDDで実装する](./phase-5-6.md) * [Phase 5.7: バリデーションとモデル責務をTDDで設計する](./phase-5-7.md) * [Phase 5.8: BaseModel / 抽象化をTDDで設計する](./phase-5-8.md) * [Phase 5.9: ORMの限界とActiveRecordの理解](./phase-5-9.md) * [Phase 6.1: 統合 — 自作コンポーネントでWebアプリケーションを構築する](./phase-6-1.md) * [最終成果物課題：発表・評価・レビュー](./goal.md) ## ライセンス © 2026 株式会社Speee (Speee, Inc.) 特記のない限り、この研修ガイダンスは[クリエイティブ・コモンズ 表示 4.0 国際ライセンス（CC BY 4.0）](https://creativecommons.org/licenses/by/4.0/deed.ja)で提供します。全文は[LICENSE](./LICENSE)を参照してください。 株式会社Speeeが権利を有する下記のコード例・コードファイルは、追加で **2-Clause BSD License（SPDX識別子: `BSD-2-Clause`）** でも提供します。全文は[LICENSE-CODE](./LICENSE-CODE)を参照してください。対象コードは **CC BY 4.0 または BSD-2-Clause のいずれかを選択して利用できます**。両方の条件を同時に満たす必要はありません。既に提供したCC BY 4.0の許諾も維持します。 ### 適用範囲 | 対象 | 利用できるライセンス | | --- | --- | | 本文、課題文、設計の説明、図表 | CC BY 4.0 | | Markdown内の実装例（Ruby・SQL・HTML・ERBなど）、実行コマンド、設定例、およびそれらに含まれるコードコメント | CC BY 4.0 または BSD-2-Clause | | `starter/`・`script/`・`test/`内のコード・設定ファイル、ルートの`Gemfile`・`Gemfile.lock`・`Rakefile`・`.ruby-version`・`.gitignore`・`.lycheeignore`、`.github/workflows/`内の設定ファイル | CC BY 4.0 または BSD-2-Clause | | 実行結果、ログ、説明用の通信例、ディレクトリ図、クレジット例 | CC BY 4.0 | | 第三者コンテンツ、リンク先の資料、依存ライブラリ | 各権利者のライセンス・利用条件 | コード例の範囲は内容で判断し、コードフェンスや言語タグの有無は問いません。本文中のインラインコードによる実装・コマンド例も含みます。説明用の通信例などを実装用データとしてBSD-2-Clauseでも提供する場合は、その例の直前に明記します。コードフェンス内にある説明文やクレジット例は、コード向け追加許諾の対象ではありません。 第三者から引用・転載した文章・図・コードは、当社による追加許諾の対象外です。出典と適用ライセンスは該当箇所の表示に従ってください。WEBrickやRackなどの参照先のソースコードや、Bundlerで取得するGemには、本教材のライセンスを適用しません。単純な事実や著作権で保護されない記述、法令上許される利用に新たな制限を課すものではありません。 ### 再利用時の表示 教材本文を転載・改変して共有する場合の推奨クレジット例です。変更内容は実際の内容に置き換えてください。 ```text 「AI時代における低レイヤーから理解するWebアプリケーション研修ガイダンス」 © 2026 株式会社Speee (Speee, Inc.) 元の教材: https://github.com/speee/training-web-app ライセンス: CC BY 4.0 https://creativecommons.org/licenses/by/4.0/ 変更内容: <変更箇所や変更日を記載。変更がなければ「変更なし」> ``` コードをBSD-2-Clauseで再配布する場合は、[LICENSE-CODE](./LICENSE-CODE)の著作権表示・2つの条件・免責条項をすべて保持してください。ソース形式ではソースとともに、バイナリ形式では配布物に付属するドキュメントその他の資料に含めます。ライセンス名や出典URLだけでは、この条件を満たしません。具体例は[利用・改変について](./CONTRIBUTING.md)を参照してください。 利用・改変する場合は、[利用・改変について](./CONTRIBUTING.md)を確認し、対象に適用されるライセンスの条件に従ってこのリポジトリをforkしてください。