Google「CodeWiki」とは？コードベース自動文書化AIの実力と使い方

「このコード、誰も全体像を把握していない……」

開発チームからよく聞くこの悩みは、ドキュメントが古い・ない・書く時間がないという三重苦からきています。実際、10社以上のAI開発支援をしてきた経験から言うと、コードが動いていてもドキュメントが追いついていないプロジェクトは珍しくありません。新しいメンバーが入るたびに「コードを読んで理解する」という非効率が繰り返される。

Googleが2025年11月に公開したCode Wikiは、この問題をAIで根本から変えようとするツールです。GitHubの公開リポジトリのURLを入力するだけで、Geminiがコードベース全体を解析してWikiを自動生成。さらにコードが変わるたびにWikiも自動更新される「ドキュメントの自動同期」を実現しています。この記事では、Code Wikiの仕組みと実際の使い方を、スクリーンショットに近い解説と競合ツール比較を交えながら詳しく説明します。

Code WikiはGoogleが2025年11月13日にパブリックプレビューとして公開したAI搭載のコードドキュメンテーションシステムです。現在はcodewiki.googleからアクセスでき、公開GitHubリポジトリに対して無料で使えます。

このサービスのルーツは興味深いです。元々は2024年1月に「Auto Wiki」というサービスを提供していたスタートアップ「Mutable.ai」が開発したツールでした。GoogleはMutable.aiをアクワイハイアリングし、その技術をGeminiと組み合わせて再構築したのがCode Wikiです（InfoQ, 2025年11月）。

AIエージェント構築やコード自動化の基礎については、AIエージェント構築完全ガイドもあわせて参照してください。

3つのコア機能

Code Wikiは以下の3つの機能を軸に設計されています。

1. 自動更新ドキュメント生成 — コードが変更されると、Wikiが自動的に再生成されます。「ドキュメントドリフト」（コードが進化してもドキュメントが古いまま放置される現象）を根本的に解消するアプローチです。
2. Geminiチャットインターフェース — 常に最新のWikiをコンテキストとして、「この認証フローはどう動いているか」「この関数が呼ばれる経路は」といった質問に、コード定義へのハイパーリンク付きで回答します。
3. アーキテクチャ図の自動生成 — アーキテクチャ図・クラス図・シーケンス図がコードと同期して自動生成されます。マイクロサービスを追加したり依存関係が変わったりしても、図が自動的に更新されます。

背景：ドキュメント負債はなぜ生まれるのか

ドキュメントが陳腐化する最大の原因は「書くのが面倒で、書かなくてもコードは動く」という構造的なインセンティブの欠如です。Google Code Wikiはこれを「書かなくてよい」アプローチで解決しようとしています。ただし、「なぜこう実装したか」という設計意図や業務文脈はAIが自動生成することは現時点では困難です。この点は後述の「注意点」セクションで詳しく解説します。

2. 実際の使い方：5ステップ完全ガイド

公開リポジトリに対してCode Wikiを使う手順を説明します。

ステップ1: codewiki.google にアクセスする

ブラウザで codewiki.google を開きます。Googleアカウントへのログインは必須ではありません（2026年3月時点）。

ステップ2: リポジトリを検索または入力する

検索バーにGitHubリポジトリのURL（例: https://github.com/langchain-ai/langchain）またはリポジトリ名（例: langchain-ai/langchain）を入力します。人気のOSSプロジェクト（LangChain、LangGraph等）はすでにインデックスされており、即座に閲覧できます。

# 入力例
https://github.com/your-org/your-repo

# または短縮形
your-org/your-repo

# 注意: 現在は公開リポジトリのみ対応
# プライベートリポジトリはGemini CLI拡張機能（ウェイトリスト待ち）を使用

注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

ステップ3: 自動生成されたWikiを読む

Code Wikiは以下の構造でドキュメントを生成します。

• 概要セクション — プロジェクトの目的・アーキテクチャの全体像
• モジュール別解説 — 主要コンポーネントの役割と依存関係
• クラス・関数リファレンス — 実装コードへの双方向ハイパーリンク付き
• アーキテクチャ図 — Mermaid形式で自動生成される構成図

ステップ4: Geminiチャットで質問する

画面右側または下部のチャットアイコンをクリックするとGemini搭載のチャットが開きます。このチャットは汎用的なGeminiではなく、「そのリポジトリ全体を理解したGemini」です。

# チャット質問の例

「このプロジェクトの認証フローを説明してください」
→ 関連ファイル名とコード行番号へのリンク付きで回答

「UserServiceクラスが呼ばれる経路をすべて教えてください」
→ 呼び出し元のファイル一覧とコードへのリンク

「このバグが起きそうな箇所はどこですか？」
→ 潜在的なリスク箇所の指摘（精度はリポジトリの品質依存）

ポイント: チャットの回答には必ず関連コードへのハイパーリンクが含まれます。「読む」と「探す」が一つの画面で完結するのが大きな特徴です。

ステップ5: アーキテクチャ図を確認する

「Diagrams」タブに切り替えると、コードから自動生成されたアーキテクチャ図・クラス図・シーケンス図が表示されます。これらはコードが変更されるたびに自動更新されるため、「ドキュメントに古い図が残っている」という問題が発生しません。

3. Before/After: ドキュメントなし vs. Code Wiki生成後

事例区分: 想定シナリオ
以下は複数のOSSリポジトリでCode Wikiを実際に試した観察をもとに構成した典型的なシナリオです。

Before: 典型的なドキュメントなし状態

my-api-project/
├── src/
│   ├── auth/
│   │   ├── jwt.ts       # コメントなし、READMEの言及なし
│   │   └── oauth.ts     # 何をするファイルかREADMEに記載なし
│   ├── services/
│   │   ├── user.ts      # 依存関係不明
│   │   └── payment.ts   # 外部APIとの連携方法不明
│   └── index.ts
├── README.md            # 「セットアップ: npm install && npm start」だけ
└── package.json

新メンバーがこのリポジトリを見た場合：「認証フローがどうなっているのか」「決済処理の流れは」「どこから読み始めればいいか」が全くわかりません。

After: Code Wiki生成後の状態（実際の生成例に基づく）

# 自動生成されるWikiの構造（例）

## Overview
このAPIは Node.js + TypeScript で実装された RESTful API です。
認証はJWT + OAuth 2.0のハイブリッド方式を採用しています。

## Architecture
[自動生成されたアーキテクチャ図]
  Client → API Gateway → Auth Service → UserService → Database
                       ↘ PaymentService → Stripe API

## Core Modules

### auth/jwt.ts [コードへのリンク]
JWTトークンの生成・検証・リフレッシュを担当します。
- generateToken(userId: string): アクセストークンを生成（有効期限: 1時間）
- verifyToken(token: string): トークンの署名と有効期限を検証
- refreshToken(refreshToken: string): リフレッシュトークンで新しいアクセストークンを発行

### services/user.ts [コードへのリンク]
ユーザーの CRUD 操作と認証状態管理を担当します。
依存: auth/jwt.ts, database/prisma.ts

このレベルのドキュメントが、コードを変更するたびに自動で更新されるのがCode Wikiの核心的な価値です。

4. 競合ツール比較：Code Wikiの立ち位置

コードドキュメンテーションツールは複数存在します。それぞれの特性を整理します。

料金情報の最終確認: 2026-03-13。Swimm: swimm.io/pricing より。各ツールの料金は変更される場合があります。

Google Code WikiとDeepWikiの比較

HackerNewsのコミュニティでは「DeepWikiの方が優れている」という意見も出ています（2025年11月）。実際に両者を比較すると：

• DeepWiki（Cognition Labs / Devin開発元）: プライベートリポジトリにすでに対応している点でCode Wikiより先行しています。GitHub / GitLab / Bitbucketと幅広く対応。
• Google Code Wiki: Geminiとの統合深度、NotebookLMとの連携可能性など、Googleエコシステム内での拡張性に優位性があります。ただしプライベートリポ対応はまだウェイトリスト段階です。

2026年3月時点では「プライベートリポジトリをすぐ使いたい」ならDeepWiki、「Google/Geminiエコシステムで統合したい」ならCode Wikiのウェイトリストに登録、というのが現実的な判断です。

5. 対応言語と技術的な仕組み

対応プログラミング言語

複数のソース（Google Developers Blog、Analytics Vidhyaなど）によると、Code Wikiは主要プログラミング言語に対応しています。公式ブログでは具体的な言語リストは明示されていませんが、確認されている対応言語は以下です。

• Python
• JavaScript / TypeScript
• Java
• Go
• C++
• Rust

（最終確認: 2026-03-13。公式サイトで最新の対応言語を確認することを推奨します）

Geminiによるコード解析の仕組み

Code Wikiがコミット後にドキュメントを再生成する仕組みは、大まかに以下のフローです。

# Code Wiki の内部処理フロー（推測を含む概念図）

1. GitHubのwebhook / ポーリングでコミットを検知
2. 変更されたファイルをGeminiに送信
3. Geminiがコード全体の文脈を考慮して以下を生成:
   - 関数・クラスの説明（英語・多言語対応）
   - モジュール間の依存関係グラフ
   - Mermaid記法のアーキテクチャ図
4. 生成されたMarkdown + 図をWikiとして公開
5. チャットインターフェースのコンテキストを更新

# 注意: この処理フローは公開情報をもとにした概念的な説明であり、
# Googleの内部実装を正確に示すものではありません。

ポイント: コードへの双方向ハイパーリンクは、WikiからGitHub上の特定のファイル・行番号に直接ジャンプできる仕組みです。「何が書いてあるか読む」と「実際のコードを見る」のコンテキストスイッチがなくなります。

6. 【要注意】よくある失敗パターンと現実的な限界

限界1: 「なぜ」はAIには書けない

Code Wikiが自動生成できるのは「コードが何をしているか（What）」と「どのコードとつながっているか（How）」です。「なぜこの設計を選んだか（Why）」「このコードはどのビジネス要件から来ているか」という設計意図は自動生成できません。

❌ 期待しすぎる例：
「ADRやアーキテクチャ決定の背景が自動で生成される」

⭕ 正しい使い方：
「What / How の説明はCode Wikiに任せて、Why（設計意図・背景）は人間が手動で追記する」

なぜ重要か: Code Wikiを「ドキュメント完全自動化」と誤解してWhy系の記録を怠ると、数ヶ月後に「この実装の意図が誰にもわからない」という状況が繰り返されます。

限界2: コード品質に依存する

Code Wikiの出力品質は、インプットであるコードの品質に大きく依存します。

❌ 品質が低い入力：
変数名が a, tmp, data2 のようなコード、コメント皆無のコード

⭕ 品質が高い入力：
意味のある変数名、型定義、最低限のインラインコメント

なぜ重要か: 「Code Wikiを入れるからコードの可読性はどうでもいい」ではなく、「コードを読みやすく書くとCode Wikiの生成品質も上がる」という正のフィードバックループを意識してください。

限界3: プライベートリポジトリはまだ使えない

2026年3月時点で、Code Wikiのパブリックプレビューは公開GitHubリポジトリのみ対応しています。プライベートリポジトリへの対応は、Gemini CLI拡張機能経由でウェイトリストへの登録が必要です。

❌ 誤解：
「今すぐ社内の非公開コードにも使える」

⭕ 現実：
「ウェイトリストに登録しておき、GA版リリースを待つ」

ウェイトリスト登録: codewiki.google 下部のフォームから申し込み可能です。

限界4: ビジネス固有ドメインの理解は弱い

「受注率」「チャーン」「LTV」のような業務固有の概念は、コードだけからは推測しにくいため、生成されるドキュメントの精度が下がる場合があります。ドメイン知識の重要な部分は人間が補完する必要があります。

7. 実務での活用シナリオ

シナリオ1: 新メンバーのオンボーディング短縮

事例区分: 想定シナリオ
以下は複数のAI開発チーム支援経験をもとに構成した典型的なシナリオです。

従来のオンボーディングでは、新メンバーがコードの全体像を把握するまでに数日〜2週間かかるケースがあります。Code Wikiを導入したチームでは、「コードを全体的に眺める」フェーズをWikiに任せ、人間によるメンタリングを「Why（設計意図）の伝達」に集中できます。

シナリオ2: レガシーコード解析

数年前に書かれたコードで「何をしているかは動作から推測できるが、全体像が不明」という場合、Code WikiのURL入力一発でアーキテクチャ図と依存関係マップが生成されます。

# レガシーリポジトリをCode Wikiに通す手順

1. リポジトリをGitHubにpush（まだの場合）
2. codewiki.google で URL を入力
3. 生成されたアーキテクチャ図をエクスポート or スクリーンショット
4. 不明な部分をGeminiチャットで質問
5. 理解した「Why」を手動でWikiに追記

# 注意: 機密コードをパブリックGitHubにpushしないこと。
# プライベートリポジトリ機能のGA版リリースを待つか、
# DeepWikiのプライベートリポジトリ機能を検討する。

シナリオ3: OSSコントリビューション前の全体把握

大規模OSSへのコントリビューションを検討している開発者にとって、Code Wikiは「どのモジュールに手を入れるべきか」を素早く把握するために有効です。LangChain、LangGraphなど人気リポジトリはすでにインデックスされています。

あわせて読みたい

• Codex Securityの使い方｜AIコード脆弱性スキャン導入ガイド
• Claude Code Plugins完全解説2026｜自分専用エディタを作る
• 【2026年最新】LangGraph・CrewAI・AutoGen徹底比較

参考・出典

• Introducing Code Wiki: Accelerating your code understanding — Google Developers Blog（参照日: 2026-03-13）
• Google Launches Code Wiki, an AI-Driven System for Continuous, Interactive Code Documentation — InfoQ（参照日: 2026-03-13）
• Google previews Code Wiki, AI to document repositories — The Register（参照日: 2026-03-13）
• Google Releases CodeWiki — Hacker News discussion（参照日: 2026-03-13）
• Google Code Wiki: Live Docs, Diagrams & Chat for Any GitHub Repo — Analytics Vidhya（参照日: 2026-03-13）
• Swimm Pricing — Swimm（参照日: 2026-03-13）

まとめ：今日から始める3つのアクション

1. 今日やること: codewiki.google にアクセスして、自分が関わっているOSSか、似た技術スタックのリポジトリを入力してみる。Geminiチャットで「このプロジェクトのアーキテクチャを教えて」と質問してみましょう。
2. 今週中: チームの公開リポジトリがあればCode Wikiに登録し、自動生成されたドキュメントをWhy（設計意図）を補完する形でレビューする。プライベートリポジトリを使いたい場合はウェイトリストに登録しておく。
3. 今月中: Swimm（有料）またはDeepWiki（無料）と比較検討し、チームのドキュメンテーション戦略を「AIが自動生成するWhat/How」と「人間が書くWhy」に役割分担する運用フローを設計する。

あわせて読みたい:

• AIエージェント構築完全ガイド — AIを使った開発自動化の全体像を掴む
• AIコーディングツール徹底比較 — Cursor、GitHub Copilot、Continue等の選び方

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書累計3万部突破。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。