> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kanaeru.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# クイックスタート

> サインインしてエージェントランタイムを設定し、最初のビジョンをアウトカムのデリバリーまで進めます。

このガイドでは、最初のサインインからアウトカムのデリバリーまでを順に説明します。セットアップは数分で終わります。デリバリーまでにかかる時間は、依頼する内容によって変わります。

<Note>
  Kanaeruは現在、招待制のクローズドベータです。料金はまだ公開していません。招待を受け取るには、Kanaeru Software Factoryのページで[ウェイトリストに登録](https://www.kanaeru.ai/ja/software-factory#launch)してください。サインイン用のリンクは招待メールに記載されています。
</Note>

<Steps>
  <Step title="サインインする">
    招待メールのリンクを開き、**Googleでサインイン**または**Microsoftでサインイン**を選びます。招待メールが届いたアドレスを使ってください。

    まだ招待を受け取っていない場合は、Software Factoryのページで[ウェイトリストに登録](https://www.kanaeru.ai/ja/software-factory#launch)してください。

    初回サインイン時には、次の操作を行います。

    1. クローズドベータの利用規約を読み、**同意して続行**を選びます。
    2. **主な役割**を選びます。Kanaはこれをもとに、どの用語を説明するかを判断します。

    組織を設定する必要はありません。組織は招待と同時に作成されているため、名前もすでに入力されています。
  </Step>

  <Step title="エージェントランタイムにサインインする">
    エージェントを動かすにはマシンが必要です。クローズドベータでは、サインインの完了時にKanaeruが**クラウドマシン**を用意します。何もインストールする必要はありませんが、マシン上のコーディングエージェント（Claude CodeやCodexなどの**ランタイム**）が作業するには、それぞれのモデルプロバイダーへのサインインが必要です。

    1. クラウドマシンを選択します。**スリープ中**と表示されている場合は**起動**を選び、1分ほど待ちます。
    2. **プロバイダー認証情報**で、使いたいランタイムごとにアクセス手段を追加します。APIキーか、Codexの**ChatGPT でサインイン**のようなサインインです。
    3. **ランタイム確認**を確認します。アクセスを設定したランタイムは、**要設定**から**利用可**に変わります。

    いずれか1つのランタイムが**利用可**になったら、**Kana に進む**を選んでチャットを開きます。ランタイムは後から追加できます。各ランタイムが対応しているプロバイダーについては[ランタイム](/ja/machines/runtimes)を参照してください。
  </Step>

  <Step title="GitHubを接続する">
    ユーザーメニューから**プロフィール**を開きます。左サイドバー下部の自分の名前を選び、**プロフィール**を選びます。コネクタのセクションで**GitHub**を選び、リポジトリを所有するアカウントまたは組織に**Kana GitHubアプリ**をインストールします。Kanaeruはこのアプリを通じてプルリクエストを作成します。[GitHub](/ja/guides/github)を参照してください。
  </Step>

  <Step title="ワークスペースを作成してビジョンを伝える">
    **新しいワークスペース**を選び、作りたいものをKanaに伝えます。**ビジョン名**と**説明**を入力します。例：

    * **ビジョン名：** 友達とオンライン人狼
    * **説明：** 6〜10人の友達が、インストールもアカウント登録もなしにブラウザで人狼を遊べる。1人が部屋を作ってリンクを共有すると全員が参加でき、ゲームは夜と昼のラウンドを進行し、誰が残っているかを管理し、接続が切れた人も再参加できる。

    **コンテキスト情報源**のステップでは、Kanaに読んでほしいものを添付します。リポジトリ、GitHubやLinearのイシュー、Slackのスレッド、Notionのページ、Figmaのファイルなど、[接続済みのサービス](/ja/guides/connectors)から選べます。情報源は一度きりのスナップショットにすることも、GitHubとSlackなら**ライブ**にすることもできます。ライブにすると、新しいイベントが届くたびにKanaがそれを把握します。

    Kanaは**ビジョン＆ロードマップ**セッションを開始します。説明に足りない点があれば質問し、項目を**アウトカム**ごとにまとめた**ロードマップ**を提案します。たとえば「参加して1ラウンド遊ぶ」「切断後に再参加する」といったアウトカムです。まだアウトカムに入っていない項目は**バックログ**で待機します。**リファインメント**セッションを開けば、いつでもKanaと一緒にロードマップを組み直せます。

    <Tip>実際の例：[Nadiaのビジョンセッション：アイデアから計画へ](https://www.kanaeru.ai/ja/blog/2026-08-31-vision-session-from-idea-to-plan)</Tip>
  </Step>

  <Step title="Kanaがアウトカムを計画する">
    アウトカムが始まると、Kanaはそのアウトカムの**計画**セッションを実行します。アウトカムを**タスク**に分割し、各タスクは1つ以上の**ユーザージャーニー**をカバーします。各ジャーニーには**受け入れ条件**（Given / When / Then形式のシナリオ）と**ブループリント**が含まれます。

    ブループリントは、コードを書く前にKanaが理解した内容を示すものです。実際の画面をクリックして操作できるライブの**UXモックアップ**のほか、ユーザージャーニー、シーケンス図、API契約、データモデルとドメインモデル、アーキテクチャ、ステートマシン、そして各選択の理由を添えた技術スタックがあります。[ブループリント](/ja/concepts/blueprints)を参照してください。

    Kanaが確信を持てない点は、**理解のギャップ**になります。理解のギャップは、影響が及ぶ最も狭い範囲（1つのジャーニー、1つのタスク、タスク一覧、またはアウトカム全体）で提起されます。通常のギャップは、情報不足、曖昧さ、仮定、記録された決定です。**ブロッキング**のギャップ（リスク、エスカレーション、仕様の不足、意図のずれ、理解度の確認、あなただけが持つ前提情報）は、実行前に解消する必要があります。[理解のギャップ](/ja/concepts/blueprints)を参照してください。

    <Tip>実際の例：[Nadiaの計画セッション：アウトカムからレビューできる作業へ](https://www.kanaeru.ai/ja/blog/2026-09-01-planning-session-from-outcome-to-reviewable-work)</Tip>
  </Step>

  <Step title="計画をレビューする">
    **ロードマップ**でアウトカムを開き、**計画とレビュー**を展開します。レビューは3つのステップで進めます。

    1. **タスク分解**：タスクの分け方は適切ですか？ **タスク分解を承認**を選びます。
    2. **ユーザージャーニー一覧**：各タスクは適切なジャーニーをカバーしていますか？ **ジャーニー一覧を承認**を選びます。
    3. **各ジャーニー**：受け入れ条件とブループリントを確認して承認し、次のジャーニーに進みます。

    理解のギャップには、**理解のギャップ**パネルで、提起されたレベルごとに回答します。

    **アウトカムを開始**は、すべてのチェックを通過したときにだけ有効になります。タスクが承認され要件がレビュー済みであること、すべてのブループリントが承認され未解決のブロッキング注釈がないこと、ブロッキングのギャップが残っていないことです。最後のチェックは**理解度クイズ**です。レビューチャットでKanaが計画を説明したあと、3〜5問の質問をします。すべてに正解する必要があります。**アウトカムを開始**を選んだら、合格したことを確認し、**確認して開始**を選びます。

    <Tip>実際の例：[Nadiaのレビューセッション：コードを書く前にバグを発見](https://www.kanaeru.ai/ja/blog/2026-09-02-review-session-caught-the-bug-before-code)</Tip>
  </Step>

  <Step title="エージェントに構築を任せる">
    各タスクの準備が整うと、**タスク計画**セッションがそのタスクの**パイプライン**を設計し、独立したレビュアーがそれをチェックします。パイプラインには必ず**ビジネスロジック**、**API**、**UI**、**QA**、**デプロイ**の5つのフェーズがあります。各フェーズにはレイヤーがあり（たとえばビジネスロジックにはドメインとユースケース）、各レイヤーは2つのサイクルを実行します。

    * **構築**：ほとんどのレイヤーは、先にコードを書き、次にテストを書きます。ユースケースはテストファーストです。生成されたコードはすべて、その場でlintの修正が行われます。
    * **レビューと修正**：レビューステップが書かれた内容をチェックし、却下された作業を修正に戻して、再度レビューします。失敗が続く場合は、エスカレーション判定が判断します。

    QAはタスクをエンドツーエンドで検証します。デプロイでは作業をコミットし、変更全体の最終レビューを行い、プルリクエストを作成します。その後エージェントは、プルリクエストがマージされるまでレビューコメントに対応し、CIを修正します。同時に実行されるタスクは最大3つです。詳しくは[パイプライン](/ja/concepts/how-kanaeru-works)を参照してください。

    進行状況はすべて**実行**タブで確認できます。アウトカムを[Koa](/ja/guides/working-with-kana)に任せている場合は、Koaがあなたに代わって進め、あなたが決めるべきことがあるときだけ、人の判断待ち受信箱である**あなた待ちの案件**にエスカレーションします。
  </Step>

  <Step title="デリバリーを出荷する">
    各タスクのプルリクエストは、アウトカム専用のブランチ（`outcome/<id>`）にマージされるため、アウトカムは1か所に積み上がっていきます。最後のタスクがマージされると、Kanaeruはリポジトリごとに1つの**デリバリープルリクエスト**を、アウトカムブランチからデフォルトブランチに向けて作成します。これをレビューしてマージすると、アウトカム全体が出荷されます。別の方法でレビューしたい場合はKanaに相談してください。たとえば、タスクのプルリクエストをスタックにしたり、1つずつベースブランチに直接マージしたりできます。

    マージされると、**実行**タブに**デリバリーの承認準備ができました**と表示されます。**振り返りを開始**を選びます。
  </Step>

  <Step title="振り返りでサイクルを締めくくる">
    振り返りでは、うまくいったこと、うまくいかなかったこと、かかったコストを確認します。フィードバックを1つ以上追加し、エビデンス（テスト、承認、そして作られたものが承認したブループリントと一致しているか）を確認してから、**デリバリーを承認し、アウトカムを完了**を選びます。振り返りで得た学びは、次のアウトカムに活かされます。
  </Step>
</Steps>

## 次のステップ

<CardGroup cols={2}>
  <Card title="Kanaeruのしくみ" icon="diagram-project" href="/ja/concepts/how-kanaeru-works">
    ビジョン、アウトカム、タスクを支える考え方。
  </Card>

  <Card title="Kanaと一緒に働く" icon="messages" href="/ja/guides/working-with-kana">
    チャット、実行中のエージェントの誘導、質問への回答。
  </Card>
</CardGroup>


## Related topics

- [Kanaeruの概要](/ja/index.md)
- [ブループリントの例](/ja/concepts/blueprint-examples.md)
- [ブループリントエディターとツール](/ja/guides/blueprint-editor.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.