《Hello 算法》コントリビューションガイド：誤字修正・コード翻訳のPull Request手順とDockerローカルデプロイまで

本書はマルチ言語対応のオープンソース書籍であり、日本語版の本文・図解・サンプルコードもすべてこのリポジトリ上で公開・更新されています。本ガイドでは、ページ右上の「編集アイコン」を使った軽微な修正から、Fork を起点とした本格的なコンテンツ制作（コード翻訳・記事拡充）の Pull Request ワークフロー、そして docker-compose.yml と Dockerfile を利用したローカル環境（http://localhost:8000）での閲覧手順までを体系的に解説します。読み終えると、誤字修正やリンク切れの報告、別言語へのサンプルコード移植、ローカルでの Web 版構築といった一連の参加フローを自分の作業として実行できるようになります。

本編は、日本語版の参加ガイド ja/docs/chapter_appendix/contribution.md を骨格とし、実際のビルド設定やテスト基盤を補足しながら進めます。

なぜオープンソース形式なのか：更新サイクルの速さが本書の強み

紙の書籍では、2 回の増刷の間隔が長く、内容の更新は非常に困難です。一方、本書のようなオープンソース書籍では、内容の更新サイクルを数日、場合によっては数時間にまで短縮できます。この特徴を支えているのが、以下の 3 点です。

1. 本文・図解・コードがすべて Markdown とプレーンテキストでリポジトリに管理されている
2. 各ページから直接編集を開始できる「編集アイコン」が Web 版に組み込まれている
3. 読者が発見した問題（誤字、リンク切れ、内容の欠落、表現の曖昧さ、説明の不明瞭さ、行文構成の問題など）を、Pull Request または Issue を通じて即座に反映できる

著者の力には限りがあるため、書籍にはどうしても一部の漏れや誤りが残ります。そのため本書では、読者の指摘や修正を歓迎し、より良い学習リソースを提供する仕組みを用意しています。すべての寄稿者の GitHub ID は、本書のリポジトリ、Web 版、PDF 版のホームページに掲載され、オープンソースコミュニティへの貢献を示す仕組みになっています（掲載方法の詳細は各版のホームページを参照してください）。

参加の前に：日本語版のドキュメント構成と動作環境の把握

日本語版のドキュメントは、リポジトリ内の ja/docs 配下に章ごとの Markdown として格納されています。本章（付録）には次のようなファイルが並んでいます。

• ja/docs/chapter_appendix/contribution.md（本ガイド）
• ja/docs/chapter_appendix/installation.md（プログラミング環境のインストール手順）
• 各章の Markdown と、その章専用の画像フォルダ（*.assets）

たとえば本章の説明画像は ja/docs/chapter_appendix/contribution.assets に格納されており、Markdown からは相対パスで参照されています。つまり、Web 版のページ右上にある「編集アイコン」から直接、この Markdown ファイルそのものを修正するのが基本フローです。

なお、コードの動作確認にはローカル環境が必要です。各言語（Python・Java・C++・C・C#・JS・Go・Swift・Rust・Ruby・Kotlin・TS・Dart など）のセットアップ手順は インストールガイド に詳述されているため、未導入の言語がある場合は先にそちらを確認してください。

コンテンツの微調整：編集アイコンから Pull Request まで

文章の小さな修正（誤字・表現の改善・リンクの修正など）を行う場合、リポジトリを直接クローンする必要すらありません。Web 版の各ページ右上に配置された「編集アイコン」を使うことで、ブラウザ上で完結します。

手順 1：編集アイコンをクリックし、Fork を承認する

表示中のページ右上にある編集アイコンをクリックします。その際「このリポジトリを Fork する必要があります」と表示された場合は、操作を承認してください。Fork とは、リポジトリを自分のアカウント配下に複製する操作で、これにより本家リポジトリを汚さずに変更を試すことができます。

手順 2：Markdown ソースを修正し、内容と書式を確認する

編集画面で Markdown ソースを直接修正します。このとき、以下に注意してください。

• 修正内容が技術的に正しいことを確認する
• 前後の文章・章構成との整合性を保つ
• 既存ページの書式（見出しレベル、表、コードブロック、!!! で始まるアドモニションなど）をできる限り統一する

手順 3：変更内容を説明し、「Propose file change」→「Create pull request」

1. ページ下部に、修正の内容を説明するコメントを入力します
2. 「Propose file change」ボタンをクリックします
3. ページ遷移後、「Create pull request」ボタンをクリックすると Pull Request を作成できます

このフローで作成された Pull Request は、レビューを経て本家リポジトリへ取り込まれます。

画像の修正方法：直接編集は不可、Issue で報告する

Markdown 本文やコードとは異なり、画像（図解・スクリーンショット）は直接修正できません。図解の不備を見つけた場合は、Issue を新規作成するか、既存ページのコメント欄で問題を説明してください。修正依頼の内容例は以下のとおりです。

• 図のどこが誤っているか（該当する章・図番号・箇所）
• 正しい表現・数値・構造はどのようなものか
• 参考になる情報源があればその内容

担当者が図を描き直し、置き換えまで対応します。

コンテンツ制作：Fork から Pull Request までの 5 ステップ

「コードを他のプログラミング言語へ翻訳する」「記事内容を拡充する」といった本格的な参加は、ローカル開発を伴う Pull Request ワークフローが推奨されます。GitHub のコードリポジトリを例に、手順は以下のとおりです。

ステップ 1：リポジトリを Fork する

GitHub にログインし、本書のコードリポジトリを自分のアカウントへ Fork します。Fork 後のリポジトリは自分の管理下に置かれるため、自由に変更や実験ができます。

ステップ 2：ローカルにクローンする

Fork したリポジトリのページを開き、git clone コマンドでローカルへ複製します。

git clone <フォークしたリポジトリのURL>

ステップ 3：コンテンツを制作し、完全なテストを行う

ローカルで本文の執筆やコードの移植を行います。このとき、サンプルコードの正しさを完全なテストで検証することが求められます。本書は言語ごとにコードが整理されており、たとえば以下のような構成です。

• codes/python：各章のサンプルコードと実行スクリプト codes/python/test_all.py
• codes/javascript：各章のサンプルコードと実行スクリプト codes/javascript/test_all.js
• codes/c、codes/cpp などは章ごとの CMakeLists.txt でビルド対象を管理

つまり、ある章の Python 版コードを移植して Go 版や Rust 版を追加した場合、その言語のテスト一式を実行して出力が一致することを確認してから提出する、という品質管理が前提です。対象言語の環境構築は、先述の インストールガイド で行えます。

ステップ 4：Commit してリモートへ Push する

ローカルでの変更を Commit し、Fork したリモートリポジトリへ Push します。変更単位を明確にし、コミットメッセージには修正内容を簡潔に記述するのが望ましいです。

git add <変更したファイル>
git commit -m "（修正内容の要約）"
git push origin <ブランチ名>

ステップ 5：Pull Request を作成する

Fork したリポジトリのページを更新（リロード）し、「Create pull request」ボタンをクリックすると、本家リポジトリに向けて Pull Request を作成できます。PR には変更の背景や検証結果を添えると、レビュアーとのやり取りがスムーズになります。

なお、多言語対応に伴う翻訳作業は、日本語版以外でも同じ PR 方式で進められています。たとえば英語版の翻訳参加ルールは en/CONTRIBUTING.md にまとめられており、「翻訳精度の担保とレビュー」を二段階で行う運用が示されています。

Docker デプロイ：1 コマンドで Web 版をローカル起動する

寄稿前の内容確認や、ビルド結果の動作確認に便利なのが Docker デプロイです。hello-algo のルートディレクトリ（リポジトリ直下）で、以下の Docker スクリプトを実行すると、http://localhost:8000 で本プロジェクトにアクセスできます。

docker-compose up -d

docker-compose.yml の実際の内容

リポジトリ直下の docker-compose.yml には、以下の構成が定義されています。

version: '3'
services:
  hello-algo:
    build: .
    image: hello-algo
    container_name: hello-algo
    ports:
      - "8000:8000"

build: . により同ディレクトリの Dockerfile からイメージが作成され、コンテナの 8000 番ポートがホストの 8000 番ポートにマッピングされます。image と container_name により、イメージ名・コンテナ名が hello-algo で固定されるため、後述の削除コマンドとの対応も分かりやすくなっています。

Dockerfile が行っていること

リポジトリ直下の Dockerfile は、python:3.10.0-alpine をベースに以下の処理を実行します。

1. PyPI をパッケージソースとして設定
2. mkdocs-material==9.5.5 と mkdocs-glightbox をインストール
3. overrides（サイトのカスタムテンプレート群）を build/overrides にコピー
4. 各言語の docs と mkdocs.yml を順にビルド
   • 簡体中文版（ルートの docs と mkdocs.yml）
   • 繁体中文版（zh-hant/docs）
   • 英語版（en/docs）
   • 日本語版（ja/docs）
   • ロシア語版（ru/docs）
5. ビルド成果物の site ディレクトリで python -m http.server 8000 を起動し、ポート 8000 を公開

つまり、日本語版の修正内容を確認するには、Markdown 編集後にローカルの Docker ビルドで表示確認するのが確実な方法です。編集対象のファイルは ja/docs 配下、日本語版のサイト設定は ja/mkdocs.yml になります。

デプロイの削除

ローカルでの確認が終わったら、以下のコマンドでデプロイ（コンテナ）を削除できます。

docker-compose down

この操作でコンテナは停止・削除されます。Docker イメージ自体も不要になった場合は、状況に応じてイメージの削除を別途検討してください（リポジトリへの変更は一切行われません）。

まとめ：参加フローの全体像

本書への参加フローは、修正規模に応じて次の 3 つに整理できます。

参加の種類	主な作業	対象となる場面
コンテンツの微調整	ページ右上の編集アイコン → Fork → Markdown 修正 → Propose file change → Create pull request	誤字・リンク切れ・表現の改善など
画像の修正依頼	Issue の新規作成またはコメントで問題を報告	図解・スクリーンショットの誤り
コンテンツ制作	Fork → clone → 制作と完全テスト → Commit → Push → Pull Request	別言語へのコード翻訳・記事拡充
Docker デプロイ	docker-compose up -d / docker-compose down	ローカルでの Web 版確認・ビルド検証

どの経路を選ぶ場合でも、「内容の正確さ」と「既存書式との統一」がレビューの基本です。日本語版の技術用語や執筆規約を確認したい場合は、付録の関連ドキュメントをあわせて参照してください。これで、読者から共同制作者への一歩を踏み出す準備が整いました。