> For the complete documentation index, see [llms.txt](https://gitbook.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://gitbook.com/docs/documentation/ja-gitbook-documentation/skill/build-integration.md).

# インテグレーションを構築する

GitBookインテグレーションを構築、開発、公開する — GitBook内で動作し、カスタムブロックの追加、イベントへの反応、OAuth経由の外部サービス接続、エディタの拡張を行うアプリ。このスキルは、〜する場合に使用する

GitBook の開発者プラットフォーム上で統合を構築するためのスキルです。GitBook 自体の内部で動作するアプリです。統合では、エディタ内にカスタムブロックを描画したり、構成用 UI を表示したり、イベント（コンテンツ更新、Git 同期完了、スペース閲覧）を監視したり、OAuth で外部サービスに対して認証したり、HTTP 経由であらゆるものと通信したりできます。

このスキルは、統合のライフサイクル — 雛形作成、実装、開発、公開 — をカバーします。ドキュメントを作成または再構成するために *site* 統合がインストールされる先としては、に委ねることがあります。 `configure-site`ページコンテンツの作成には、に委ねます。 `write-docs`.

## 統合とは何か（メンタルモデル）

統合は、GitBook のランタイムによって実行される小さな TypeScript アプリです。ページに注入されるスクリプトでも、ユーザーのサーバー上で動作するコードでもありません。以下の 3 つの結果が、他のすべてを形作ります:

1. **レンダリングは GitBook のバックエンドで行われます。** コンポーネントの `render` 関数は、やり取りのたびにサーバー側で実行され、ContentKit のマークアップ（JSX 風の UI 記述）を返します。あなたが制御できるクライアント側の React ツリーも、DOM へのアクセスもなく、UI の更新は action → 新しい state → 再レンダー のループを通って流れます。
2. **サイトに JavaScript を注入することはできません。** この `site:script:inject` と `site:script:cookies` GitBook 所有の統合で見かける scopes は内部専用です。ユーザーの要望が「ドキュメントに script タグを追加する」ことに相当するなら、早い段階で止めてそう伝えてください。サポートされている手段は、カスタムブロック、webframe、イベントです。
3. **ローカル開発はプロキシであり、アクセスするサーバーではありません。** `gitbook dev` は *インストール済みの* 統合のトラフィックをあなたのマシンに転送します。開発サーバーのポートをブラウザで直接開くことはありません。app.gitbook.com 内で統合を操作します。

## プロジェクトは

`gitbook new` この形を雛形として作成します:

```
my-integration/
├── gitbook-manifest.yaml   # identity, scopes, blocks, configuration schema
├── .gitbook-dev.yaml       # local dev config (`gitbook dev` により生成)
├── package.json
└── src/
    └── index.tsx           # エントリーファイル — default-exports createIntegration()
```

エントリーファイル（ `script:` マニフェスト内のが指す先）で default export される `createIntegration({ fetch, components, events })`:

```tsx
import { createIntegration, createComponent } from '@gitbook/runtime';

const helloBlock = createComponent({
    componentId: 'hello-world',            // マニフェスト内のブロック id と一致している必要があります
    initialState: { message: 'Say hello!' },
    action: async (element, action, context) => {
        switch (action.action) {
            case 'say':
                return { state: { message: 'Hello world' } };
            default:
                return {};
        }
    },
    render: async (element, context) => (
        <block>
            <button label={element.state.message} onPress={{ action: 'say' }} />
        </block>
    ),
});

export default createIntegration({
    components: [helloBlock],
    events: {
        space_content_updated: async (event, context) => {
            // コンテンツ変更に प्रतिक्रिया
        },
    },
});
```

カスタムブロックは、エディタの挿入パレット（⌘ + /）に表示されるには、 **両方の** 場所で宣言されている必要があります: `createComponent` コード内の *と* a `blocks:` というマニフェスト内のエントリで `id` が `componentId`と一致していること。片方を忘れるのは、「ブロックが表示されない」原因として最もよくあるものです。

## マニフェストの要点

`gitbook-manifest.yaml` は統合の識別情報と権限付与です。必須項目: `name` （GitBook 全体でグローバルに一意である必要があります。 `acme-changelog`を読み、 `のような名前空間付きのものを選んでください）`), `title`, `description`, `organization` （組織 ID またはサブドメイン）、 `visibility`, `scopes`、そして `script`。コードが実際に使用する scopes のみを要求してください。インストーラーに表示されます。

マニフェストにはさらに `blocks`、インストーラー向けの `configurations` （アカウントレベルおよびサイトレベルのプロパティスキーマを設定フォームとして表示するもの）、そして `secrets` （例: `CLIENT_ID: ${{ env.CLIENT_ID }}`、公開時に読み込まれます — `dotenv-cli` を使って `gitbook publish` があなたの `.env`).

完全なフィールド別スキーマ、scope 一覧、configuration プロパティ型: `references/manifest.md`。基本を超えてマニフェストを編集するときは、必ず読んでください。

## 開発ループ

このループには分かりにくい順序があります — **公開がローカル開発より先です**:

1. **前提条件。** Node 18+、<https://app.gitbook.com/account/developer> から取得した個人アクセストークン、そして CLI: `npm install @gitbook/cli -g`、その後 `gitbook auth` （または `gitbook auth --token=<token>`）。会話にトークンを貼り付ける必要がある場合は、環境変数にエクスポートし、決してそのまま返したりコミットしたりしないでください。
2. **雛形作成。** `gitbook new <dir>` — 名前、タイトル、組織、scopes を順に入力するよう促されます。
3. **一度公開します。** `gitbook publish` をプロジェクトのルートで実行します。これにより統合（既定では非公開）が登録され、インストールリンクが表示されます。
4. **それを** 少なくとも 1 つのスペースまたはサイトに、そのリンク経由でインストールします。どこかにインストールされるまではローカル開発は動作しません。
5. **開発。** `gitbook dev` を開始するとプロキシが立ち上がります。インストール済みの統合へのすべてのトラフィックは、公開済みバージョンではなくローカルコードから提供されます。サーバー URL ではなく GitBook エディタ内で操作してください。UI の変更にはブラウザの更新が必要です。より快適なループにするにはブラウザキャッシュを無効にしてください。ログは、コードが動作している場所に応じて *ブラウザ* のコンソールまたはターミナルに表示されます。ログ出力が壊れていると結論づける前に、両方確認してください。
6. **再公開** を `gitbook publish` して、ホストされているバージョンを更新したいときはいつでも。 `gitbook unpublish <name>` で削除されます。

CLI コマンドリファレンス（ `gitbook whoami` と `gitbook openapi publish`): `references/manifest.md`.

## Runtime: fetch, events, environment, OAuth

詳細と完全な表は `references/runtime.md` にあります。イベントハンドラー、OAuth フロー、または `context.environment`に触れるものを書くときは、そこを読んでください。要点は次のとおりです:

* **`fetch`** は標準の Fetch API `Request`/`Response` オブジェクトを使って、統合の公開エンドポイントへの着信 HTTP リクエストを処理します。外向きの HTTP も通常の `fetch` です。
* **`events`** はイベント名（`installation_setup`, `space_installation_setup`, `space_view`, `ui_render`, `space_content_updated`, `space_visibility_updated`, `space_gitsync_started`, `space_gitsync_completed`）をハンドラーに対応付けます。一部のイベントには一致する scopes が必要です。
* **`context.environment`** は `apiEndpoint`, `apiTokens`、インストール情報（スペース、ステータス、インストールごとの `configuration` 値（インストーラーが入力したもの）、 `secrets`、および公開 URL（`environment.integration.urls.publicEndpoint`).
* **OAuth** を外部プロバイダーに対して行うときは、決まったパターンがあります。 `button`型の configuration プロパティで、その `callback_url` が `createOAuthHandler({...})` にルーティングされ、client id/secret は `secrets`から取得します。リダイレクトやトークン交換を自前で実装しないでください。
* **統合の内部から GitBook API を呼び出すときは**: `context.api` を使ってください（認証済みの `@gitbook/api` クライアント）— 生のトークンから独自クライアントを構築しないでください。

## ContentKit: UI の構築

ContentKit はコンポーネントの語彙です `render` が返せるもの: レイアウト（`block`, `vstack`, `hstack`, `divider`）、表示（`box`, `card`, `text`, `image`, `markdown`）、およびインタラクティブ要素（`button`, `textinput`, `select`, `switch`, `checkbox`, `radio`, `codeblock`, `webframe`, `modal`）。インタラクティブモデルを一言で言うと、入力は値を `state` キーにバインドし、ボタンは actions を送出し、あなたの `action` reducer が新しい state を返し、GitBook が再レンダーします。

を読んでください `references/contentkit.md` — ライブプレビューのための動的 state バインディング、webframe `postMessage` 通信、 `returnValue`付きのモーダル、 `@editor.node.updateProps`による props の永続化、 `@link.unfurl` + `urlUnfurl` を使ったリンクの展開、マニフェストパターン、そしてブロックの Markdown コードブロックシリアライズなど、推測しにくいパターンがすべて載っています。

## 公開と共有

マニフェスト内の visibility が到達範囲を制御します:

* `private` （既定）— 所有組織のメンバーのみがインストール可能です。内部ツールに適しています。開発中はここに留めてください。
* `unlisted` — 任意の組織がインストール可能ですが、共有インストールリンク経由のみです。特定の顧客やベータテスターに共有するのに適しています。
* `public` — 誰でもインストール可能です。インテグレーションマーケットプレイスに提出する前に必要です（これは別の審査プロセスです — GitBook の「アプリを審査に出す」ドキュメントを参照してください）。

再実行 `gitbook publish` して、visibility を変更したあとに。 `public`を提案する前に、マニフェストが見栄えのよい状態か確認してください: `icon`, `summary` （Markdown、2048 文字以下）、 `previewImages` （1600×800）、 `categories`, `externalLinks`.

## 作業スタイル

* **新しく始めるときは手作業ではなく CLI で雛形作成する** — `gitbook new` がマニフェスト、TypeScript 設定、そして `@gitbook/runtime` の各バージョンを正しく配線します。
* **ブロックの id チェーンを追跡する** （マニフェスト `blocks[].id` ↔ `componentId`）— コンポーネントの挙動がおかしいときはいつでも。
* **秘密情報はマニフェストファイル自体に入れない** — 常に `${{ env.X }}` という間接参照を使い、リテラル値は使わないこと。
* **ユーザーの目的が&#x20;*****外部からの*****&#x20;GitBook** コンテンツやサイトの自動化（REST API を叩くスクリプト、CI パイプライン）である場合、統合は適切な手段ではないことがあります。個人トークンを使う通常の API のほうがシンプルです。コードを *内部で* GitBook の中で動かす必要があるときに、統合の価値が生まれます: ブロック、設定 UI、イベント反応、インストーラーを代理した OAuth。

## リファレンス

* `references/manifest.md` — すべての `gitbook-manifest.yaml` フィールド、全 scope、configuration プロパティ型、secrets、CLI コマンドリファレンス、インストール/設定フロー。
* `references/runtime.md` — `createIntegration` / `createComponent` / `createOAuthHandler` のシグネチャ、イベントカタログ、 `context.environment` の形、HTTP の入出力。
* `references/contentkit.md` — props、組み込み actions、インタラクティブ性のレシピ（動的バインディング、webframe、モーダル、展開、Markdown シリアライズ）を含む完全なコンポーネントリファレンス。


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://gitbook.com/docs/documentation/ja-gitbook-documentation/skill/build-integration.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
