クイックスタート

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

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

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 キー（または Claude Pro/Max のログイン）、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 をポーリングする場合のみ） — Takuto が振る舞うアカウントの Atlassian API トークン。

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

2. CLI をインストール

Homebrew（macOS / Linux — 推奨）:

brew install takuto-team/tap/takuto

バイナリの手動ダウンロード（Windows を含む）については、 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:8080、 takuto setup で別のポートを選んだ場合はそのポートです。takuto start は（初回起動時に）イメージを pull し、スタックを立ち上げます。初回起動時、ダッシュボードは最初の admin アカウントの作成を促します。

6. 認証してプロジェクトを追加

ステップ 1 のトークンを追加し、Takuto をリポジトリに向けます:

推奨 — ステップ 1 のトークン: プロバイダーのキーと GitHub トークン（ANTHROPIC_API_KEY、CURSOR_API_KEY、OPENAI_API_KEY、範囲を絞った GH_TOKEN など）をダッシュボードの Configuration 画面から入力するか、起動前に .takuto/takuto.env に設定します（設定を参照）。
ダッシュボードで 「Setup a New Project」 をクリックして、Takuto に作業させたいリポジトリを clone します。
Jira または GitHub Issues を設定していれば、ポーリングが自動で始まり、「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 は再起動を生き延びます — 一時停止中や進行中の実行は自動的に再開されます。