クイックスタート

定番の「今すぐ試す」道のりです: Takuto CLI をインストールし、 takuto setup に続いて takuto start を実行して、あとはダッシュボードで仕上げます。所要時間は数分です。

プロバイダーの動作確認状況（ベータ）。 Claude Code は Anthropic がヘッドレスモードで API キーを必須にする前 に最後の動作確認を行ったきりで、Codex はまだ未検証 です。どちらも動作するはずですが、細かい引っかかりに遭遇するかもしれません。その際はぜひお知らせください — フィードバックは大歓迎で、問題の早期解決につながります。

おすすめのセットアップ。 いくつかの選択をしておくと、いちばんスムーズで本番運用にも耐える実行になります:

GitHub の認証は、personal access token（PAT）ではなく GitHub App で行いましょう。 そうすれば PR は、あなた個人のアカウントではなく専用の bot 名義 で開かれます — オーサーシップがすっきりし、アクセス範囲もアプリが付与した分だけに保たれます。

エージェントが対象とするブランチを保護しましょう。 自律エージェントは、そのトークンが許す範囲なら何でもできます。だからこそ main（および対象となるあらゆるブランチ）で branch protection を有効にしてください: マージ前に PR を必須にし、承認レビューを必須にし、直接の push を禁止します。bot 名義と組み合わせれば、ひとりで作業していても、必ず通るレビューゲートが手に入ります。

外部データベース（Postgres / MySQL / MariaDB）を使いましょう。 データが container の外に置かれ、バックアップ できるようになります。

以下の手順はこれらなしでも動きますが、早めに設定しておく価値があります。

CLI を使わずに自分でエンジンを動かしたいですか? 自分で container を構築する方法は Takuto Core のインストール を参照してください。

1. 必要なトークンを用意する

始める前に、これらを用意しておきましょう — ダッシュボードで追加します（ステップ 6）:

AI プロバイダーの認証情報 — 次のいずれか: Claude Code 向けの Anthropic API キー（ヘッドレスモードでは現在 API キーが必須です）、Codex 向けの OpenAI API キー、 Cursor Agent 向けの Cursor API キー — あるいは OpenCode 経由でセルフホストモデルを動かすなら、不要です。
GitHub アクセス — Takuto が作業するリポジトリに範囲を絞った fine-grained personal access token（Contents と Pull requests: read & write、 Metadata: read、GitHub Issues をポーリングするなら Issues: read & write）。さらに望ましいのは、 PR があなた個人のアカウントではなく範囲を絞った bot 名義から開かれるよう、 GitHub App を設定することです。
Jira（Jira をポーリングする場合のみ） — あなた自身の Atlassian API トークン。各ユーザーがダッシュボード（Configuration → Ticketing）で自分のトークンを追加すると、読み書きは あなた として行われます。デプロイ全体の所有者トークンは、まだ自分のトークンを追加していないユーザーのためのフォールバックにすぎません。

すべてのトークンは、必要最小限の範囲に絞ってください — これらが、自律エージェントの到達できる範囲を画する境界になります。

2. CLI をインストール

macOSLinuxWindowsWindows (WSL)

Homebrew（推奨）:

brew install takuto-team/tap/takuto

または binary を直接取得します:

# Apple Silicon（arm64） — Intel は takuto-darwin-amd64
curl -L -o takuto https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-darwin-arm64
chmod +x takuto && sudo mv takuto /usr/local/bin/

Homebrew（推奨）:

brew install takuto-team/tap/takuto

または binary を直接取得します:

# amd64 — arm64 は takuto-linux-arm64
curl -L -o takuto https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-linux-amd64
chmod +x takuto && sudo mv takuto /usr/local/bin/

binary をダウンロードして PATH に追加してください。PowerShell では:

# 最新の Windows binary をダウンロード
curl.exe -L -o takuto.exe https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-windows-amd64.exe
# その後 takuto.exe を PATH に含まれるフォルダー（例: ツール用ディレクトリ）に移動します

WSL の中は Linux 環境なので、Linux と同じ方法でインストールします。WSL ディストリビューションから Docker（例: WSL 統合を有効にした Docker Desktop）に到達できることを確認してください。

Homebrew（推奨）:

brew install takuto-team/tap/takuto

または binary を直接取得します:

# amd64 — arm64 は takuto-linux-arm64
curl -L -o takuto https://github.com/takuto-team/takuto-cli/releases/latest/download/takuto-linux-amd64
chmod +x takuto && sudo mv takuto /usr/local/bin/

すべての binary とチェックサムについては、Releases ページと CLI リファレンスを参照してください。

3. 前提条件

インストールが必要なのは Docker または Podman だけです — CLI がどちらがあるかを自動検出します。

Takuto Core のイメージを自分で pull する必要はありません: takuto start が初回起動時に取得します（オフラインのときはキャッシュ済みのコピーにフォールバックします）。イメージは公開で配布されているため、レジストリ認証は不要です — もちろん、お好みなら docker pull ghcr.io/takuto-team/takuto-core:latest で事前に手動で pull しておくこともできます。

4. 設定を生成

takuto setup

ウィザードは短く済みます: いまや設定のほとんどはダッシュボードが扱うため、尋ねられるのは ダッシュボードのポート と、外部データベース（Postgres / MySQL / MariaDB）を使う場合はその 接続情報 だけです（使わなければ組み込みの SQLite がデフォルトになります）。それ以外 — チケット管理システム、AI プロバイダーとモデル、ポーリング、workflow — はすべて、あとからダッシュボードで設定します。ウィザードは takuto.yml と、config.toml、シークレット（takuto.env）、スターターのパイプライン定義が入った workflows/ フォルダーを備えた .takuto/ フォルダーを生成します:

takuto.yml                  # Docker Compose のオーケストレーション
.takuto/
  config.toml                # bootstrap 設定
  takuto.env                # シークレットと API トークン
  workflows/                 # パイプラインのステップ定義
    implement_ticket.toml
    merge_base.toml
    address_pr_comments.toml

.takuto/ フォルダーは コマンドを実行した場所 に作られます — プロジェクトディレクトリである必要は ありません。別々のフォルダーで takuto setup/takuto start を実行すれば、複数の 隔離された Takuto インスタンス を並べて動かせます: それぞれが独自の設定、認証、ワークスペース、データベースを持ち、追加の設定は何も要りません。

外部データベース — とくに container で動かしているもの — に向けますか? 唯一の厄介な点は接続文字列を正しく書くことです: 外部データベース を参照してください。

5. Takuto を起動

takuto start

あとはブラウザでダッシュボードを開きます — デフォルトは http://localhost

、 takuto setup で別のポートを選んだ場合はそのポートです。takuto start は（初回起動時に）イメージを pull し、スタックを立ち上げます。初回起動時、ダッシュボードは最初の admin アカウントの作成を促します。

6. ダッシュボードで仕上げる

初回起動時、ダッシュボードは短いセットアップウィザードを順番に案内します:

GitHub — あなたの PAT、または bot 名義のコミットと PR のための GitHub App。
Repositories — Takuto に作業させたいリポジトリを clone します。
AI provider — プロバイダーのキー（ANTHROPIC_API_KEY、CURSOR_API_KEY、 OPENAI_API_KEY など）、またはセルフホストのエンドポイント。
Ticketing — Jira または GitHub Issues に加えて、リポジトリごとに設定する リポジトリ単位 のポーリング（プロジェクトキー、項目タイプ、フィルター）。各ユーザーは自分の Jira トークンをここで追加します。
Workflows — シードされた TOML パイプラインを確認します。

既存の値は各フィールドに事前入力されます（シークレットは •••••• のプレースホルダーで表示）。起動前に .takuto/takuto.env にシークレットを入れておくこともできます（設定を参照）。リポジトリとチケット管理が設定されると、ポーリングが自動で始まり「To Do」チケットを拾います — または + をクリックして説明を貼り付け、workflow を手動で開始します。

任意 — takuto auth（非推奨）。 takuto auth は CLI から対話式の OAuth ログイン（GitHub + AI プロバイダー）を実行します。OAuth は広範なアカウントアクセスを与えるため、代わりに範囲を絞った API キー/トークン（上記）を推奨します。対話式のログインフローがどうしても必要な場合にだけ takuto auth を使ってください。

次に起こること

各 workflow はベースブランチから git worktree を作成し、worktree 初期化コマンド（例: npm ci）を実行してから、TOML の workflow 定義のエージェントステップを実行します。各 workflow カードでライブのターミナル出力を見ながら、Open editor でどの worktree にもブラウザベースの VS Code エディターを開けます。

workflow ライフサイクルの全体は 仕組み を、stop、restart、マルチプロジェクトの隔離については CLI リファレンス を参照してください。

停止と再起動

takuto stop       # Takuto のサービスを停止
takuto restart    # Takuto のサービスを再起動

すべての認証状態、workflow のスナップショット、キャッシュは名前付きの Docker ボリュームに置かれるので、workflow は再起動を生き延びます — 一時停止中や進行中の実行は自動的に再開されます。