初めてですか? まずはクイックスタートから。チームで運用しますか? Takuto Core のインストールを参照。挙動を調整しますか? 設定リファレンスにすべてのキーがあります。

よくある質問

Q: Takuto を自由に使えますか?

はい。 自分の用途のために Takuto Core をセルフホストすること — 自分のマシン上でも、社内でも — は無料です: プロジェクトへの料金も、シート数の制限も、押し付けられる利用上限もありません。エンジンは FSL-1.1-ALv2 のもとで source-available、Takuto CLI は MIT なので、競合しないあらゆる用途で自由に実行・改変・セルフホストできます。テレメトリは一切なく、phone-home もありません。 知っておく価値のある唯一の制限はこれです: FSL は 競合する用途 を禁じています — Takuto Core を使って、競合するプロダクトやホスティング型サービスを提供することはできません。社内での利用、評価、プロフェッショナルサービスを通じたクライアント業務は問題なく、各バージョンはリリースの 2 年後に Apache-2.0 へ変換されます。これらの条件が合わない場合は、ご連絡ください。

Q: 運用コストはどれくらいですか?

Takuto Core 自体があなたに課金することはありません — 課金するのは AI プロバイダーです。 エージェントはあなたのアカウントで Claude Code、Cursor Agent、Codex、またはセルフホストモデルを 動かし、各チケットはコードベースの規模、プロンプトのコンテキスト、workflow のステップ数に比例して トークンを消費します。 実際のコストは選ぶプロバイダーとモデルによって大きく変わります。最新の料金を確認し、最初の数回の実行で自分のワークロードの感覚をつかんでください。 コスト削減の手立て: 決定論的な作業（lint、テスト）には コマンドステップ を使う — AI トークンを消費しません。 [jira] ticket_context_max_description_bytes でコンテキストを制限する。 実際のバックログに向ける前に [general] dry_mode = true でリハーサルする。 OpenCode 経由の セルフホストモデル はトークン単位の課金を完全になくします（払うのは ハードウェア代だけ） — セルフホストモデル を参照。

Q: 本番運用に耐えますか?

Takuto Core は ベータ です。今日から使え、実際に workflow を回している人もいます — ただし 粗削りな部分は想定してください。そして、あらゆるフィードバックを歓迎します。このサイト全体の メッセージが「エンタープライズ対応」よりも「試して、壊れたところを教えて」寄りなのも、 ベータだからです。すべての報告が、プロジェクトの次の行き先を形づくる助けになります。

Q: 貢献できますか? なぜ pull request を受け付けないのですか?

Takuto Core は source-available ですが、作者は今のところ pull request を受け付けていません。 これは 法的な理由 による意図的かつ一時的な姿勢です: プロジェクトを観察し、適切に体制を 整えるための時間が必要なのです — 外部のコードを責任を持ってマージできるようになる前に、 コントリビューターのライセンス、ガバナンス、商標のすべてを整える必要があります。 それは、フィードバックが歓迎されないという意味では ありません — むしろ逆です。 バグ報告、機能リクエスト、一般的なフィードバックは大いに求めています。 issue を立てるか、 takuto-team@proton.me までご連絡ください。制限はあくまで外部コードの マージに対してであって、プロジェクトをめぐる対話に対してではありません。

Q: ライセンスは何ですか?

2 つのコンポーネント、2 つのライセンス: Takuto Core（セルフホストするエンジン）は Functional Source License 1.1 （FSL-1.1-ALv2） のもとで source-available です: 競合しないあらゆる用途で無料で、各バージョンは リリースの 2 年後に Apache-2.0 へ変換されます。競合するプロダクトやホスティング型サービスの 提供には使えません。これらの条件が合わない場合は、 takuto-team@proton.me までご連絡ください — 喜んでご相談に応じます。 Takuto CLI（コンパニオンのセットアップツール）は MIT のもとでライセンスされています。 Takuto Core のソースは https://github.com/takuto-team/takuto-core に、CLI は https://github.com/takuto-team/takuto-cli に あります。

Q: データやテレメトリを収集しますか?

いいえ。Takuto Core はテレメトリを一切収集も送信もしません — 使用状況の分析も、 クラッシュレポーターも、phone-home もありません。ソースで自分で確認できます。 すべての送信トラフィックは egress firewall を通ります: デフォルトですべてをブロックし、実行に 必要なものだけ — あなたの AI プロバイダー、GitHub/Jira、パッケージレジストリ — を許可します （[network] extra_egress_hosts で追加できます）。あなたのチケットの内容、ソースコード、プロンプトは、 あなたが選んだ AI プロバイダーにのみ送られます — Takuto Core 自体がそれらを見ることはありません — そしてセルフホストモデルを使えば、何もインフラの外に出ません。

Q: どう隔離されていますか? エージェントを自律で動かしても安全ですか?

隔離は中核的な設計目標です: 各エージェントはそれぞれ専用の container で動作する ので、prompt injection 攻撃の影響範囲は その container に限定されます。 egress firewall が、どのエージェントもネットワーク越しに到達できる範囲を制限します。 デフォルトの許可リストは実行に必要なホスト以外をすべてブロックします — 最も厳格な設定ですが、 GitHub のような CDN 配下のサービスでは全ホストを列挙するのが面倒になります。それが現実的でない場合は、 代わりに [network] allow_all_https で送信 HTTPS をすべて許可できます。上記の container ごとの 隔離と組み合わせれば、それでも健全な構えです。 ブランチ保護は必須 — エージェントはブランチを push して PR を開き、main に直接コミットする ことはありません。権限を絞ったトークン（きめ細かい GitHub PAT、限定された Jira サービス アカウント）と組み合わせることで、乗っ取られたセッションが実際にできることを限定します。 Takuto Core はチケットの文章のまわりに明示的な「信頼できないコンテンツ」のフレーミングと 任意のバイト上限を加えており、これは prompt injection のリスクを低減しますが、ゼロにはしません — PR に対する人間のコードレビューが最後の砦であり続けます。

Q: どの AI エージェントに対応していますか?

Claude Code Cursor Agent Codex OpenCode（セルフホストモデルのみ） プロバイダーは 設定 → AI Settings で選び、それぞれ独自の [agent.providers. ] 設定を持ちます。設定リファレンス を参照してください。

Q: どんなハードウェアが必要ですか?

これらの数値は厳密な要件ではなく、おおよその目安です — 実際に必要なものは、プロジェクト、 プロバイダー、そして並列数によって変わります。参考までに、作者は Apple M1 Pro、RAM 16 GiB で Takuto Core を開発・実行しています。 RAM: 単一 workflow なら 8 GiB 以上。Podman を使う macOS では 12 GiB 以上（VM 自体に 取り分が必要）。[general] max_concurrent_workflows でスケールします。 ディスク: 30 GiB 以上の空き — worktree、npm/cargo キャッシュ、mise のツールチェーン、 オプションの Docker-in-Docker 層は、すべて Docker ボリュームに置かれます。 OS: サーバーへのデプロイには Linux ホストを推奨。ローカル利用なら macOS でも快適に動きます。 セルフホストモデル はかなり多くを必要とします — 提供するつもりのモデルに合わせて GPU/VRAM をサイジングしてください。

Q: localhost を使うとデータベース接続が失敗するのはなぜですか?

Takuto は container の中で動くので、localhost の接続文字列は データベースではなく Takuto 自身を指してしまいます。共有の Docker ネットワーク上で、データベース container の サービス名とその内部ポート を使ってください（例: postgres://…@postgres:5432/…）— localhost や ホスト側で公開したポートではありません。CLI を使う場合は、takuto setup で 「このマシンで動作している データベース container」 を選べば、これを自動で設定してくれます。 外部データベース を参照してください。

Takuto を自由に使えますか?

はい。 自分の用途のために Takuto Core をセルフホストすること — 自分のマシン上でも、社内でも — は無料です: プロジェクトへの料金も、シート数の制限も、押し付けられる利用上限もありません。エンジンは FSL-1.1-ALv2 のもとで source-available、Takuto CLI は MIT なので、競合しないあらゆる用途で自由に実行・改変・セルフホストできます。テレメトリは一切なく、phone-home もありません。

知っておく価値のある唯一の制限はこれです: FSL は 競合する用途 を禁じています — Takuto Core を使って、競合するプロダクトやホスティング型サービスを提供することはできません。社内での利用、評価、プロフェッショナルサービスを通じたクライアント業務は問題なく、各バージョンはリリースの 2 年後に Apache-2.0 へ変換されます。これらの条件が合わない場合は、ご連絡ください。

運用コストはどれくらいですか?

Takuto Core 自体があなたに課金することはありません — 課金するのは AI プロバイダーです。 エージェントはあなたのアカウントで Claude Code、Cursor Agent、Codex、またはセルフホストモデルを動かし、各チケットはコードベースの規模、プロンプトのコンテキスト、workflow のステップ数に比例してトークンを消費します。

実際のコストは選ぶプロバイダーとモデルによって大きく変わります。最新の料金を確認し、最初の数回の実行で自分のワークロードの感覚をつかんでください。

コスト削減の手立て:

決定論的な作業（lint、テスト）には コマンドステップ を使う — AI トークンを消費しません。
[jira] ticket_context_max_description_bytes でコンテキストを制限する。
実際のバックログに向ける前に [general] dry_mode = true でリハーサルする。
OpenCode 経由の セルフホストモデル はトークン単位の課金を完全になくします（払うのはハードウェア代だけ） — セルフホストモデルを参照。

本番運用に耐えますか?

Takuto Core は ベータ です。今日から使え、実際に workflow を回している人もいます — ただし粗削りな部分は想定してください。そして、あらゆるフィードバックを歓迎します。このサイト全体のメッセージが「エンタープライズ対応」よりも「試して、壊れたところを教えて」寄りなのも、ベータだからです。すべての報告が、プロジェクトの次の行き先を形づくる助けになります。

貢献できますか? なぜ pull request を受け付けないのですか?

Takuto Core は source-available ですが、作者は今のところ pull request を受け付けていません。 これは 法的な理由 による意図的かつ一時的な姿勢です: プロジェクトを観察し、適切に体制を整えるための時間が必要なのです — 外部のコードを責任を持ってマージできるようになる前に、コントリビューターのライセンス、ガバナンス、商標のすべてを整える必要があります。

それは、フィードバックが歓迎されないという意味では ありません — むしろ逆です。 バグ報告、機能リクエスト、一般的なフィードバックは大いに求めています。 issue を立てるか、 morphet.contact@gmail.com までご連絡ください。制限はあくまで外部コードのマージに対してであって、プロジェクトをめぐる対話に対してではありません。

ライセンスは何ですか?

2 つのコンポーネント、2 つのライセンス:

Takuto Core（セルフホストするエンジン）は Functional Source License 1.1 （FSL-1.1-ALv2） のもとで source-available です: 競合しないあらゆる用途で無料で、各バージョンはリリースの 2 年後に Apache-2.0 へ変換されます。競合するプロダクトやホスティング型サービスの提供には使えません。これらの条件が合わない場合は、 morphet.contact@gmail.com までご連絡ください — 喜んでご相談に応じます。
Takuto CLI（コンパニオンのセットアップツール）は MIT のもとでライセンスされています。

Takuto Core のソースは https://github.com/takuto-team/takuto-core に、CLI は https://github.com/takuto-team/takuto-cli にあります。

データやテレメトリを収集しますか?

いいえ。Takuto Core はテレメトリを一切収集も送信もしません — 使用状況の分析も、クラッシュレポーターも、phone-home もありません。ソースで自分で確認できます。

すべての送信トラフィックは egress firewall を通ります: デフォルトですべてをブロックし、実行に必要なものだけ — あなたの AI プロバイダー、GitHub/Jira、パッケージレジストリ — を許可します（[network] extra_egress_hosts で追加できます）。あなたのチケットの内容、ソースコード、プロンプトは、あなたが選んだ AI プロバイダーにのみ送られます — Takuto Core 自体がそれらを見ることはありません — そしてセルフホストモデルを使えば、何もインフラの外に出ません。

どう隔離されていますか? エージェントを自律で動かしても安全ですか?

隔離は中核的な設計目標です:

各エージェントはそれぞれ専用の container で動作する ので、prompt injection 攻撃の影響範囲はその container に限定されます。
egress firewall が、どのエージェントもネットワーク越しに到達できる範囲を制限します。デフォルトの許可リストは実行に必要なホスト以外をすべてブロックします — 最も厳格な設定ですが、 GitHub のような CDN 配下のサービスでは全ホストを列挙するのが面倒になります。それが現実的でない場合は、代わりに [network] allow_all_https で送信 HTTPS をすべて許可できます。上記の container ごとの隔離と組み合わせれば、それでも健全な構えです。
ブランチ保護は必須 — エージェントはブランチを push して PR を開き、main に直接コミットすることはありません。権限を絞ったトークン（きめ細かい GitHub PAT、限定された Jira サービスアカウント）と組み合わせることで、乗っ取られたセッションが実際にできることを限定します。

Takuto Core はチケットの文章のまわりに明示的な「信頼できないコンテンツ」のフレーミングと任意のバイト上限を加えており、これは prompt injection のリスクを低減しますが、ゼロにはしません — PR に対する人間のコードレビューが最後の砦であり続けます。

どの AI エージェントに対応していますか?

Claude Code
Cursor Agent
Codex
OpenCode（セルフホストモデルのみ）

プロバイダーは 設定 → AI Settings で選び、それぞれ独自の [agent.providers.<name>] 設定を持ちます。設定リファレンスを参照してください。

どんなハードウェアが必要ですか?

これらの数値は厳密な要件ではなく、おおよその目安です — 実際に必要なものは、プロジェクト、プロバイダー、そして並列数によって変わります。参考までに、作者は Apple M1 Pro、RAM 16 GiB で Takuto Core を開発・実行しています。

RAM: 単一 workflow なら 8 GiB 以上。Podman を使う macOS では 12 GiB 以上（VM 自体に取り分が必要）。[general] max_concurrent_workflows でスケールします。
ディスク: 30 GiB 以上の空き — worktree、npm/cargo キャッシュ、mise のツールチェーン、オプションの Docker-in-Docker 層は、すべて Docker ボリュームに置かれます。
OS: サーバーへのデプロイには Linux ホストを推奨。ローカル利用なら macOS でも快適に動きます。
セルフホストモデル はかなり多くを必要とします — 提供するつもりのモデルに合わせて GPU/VRAM をサイジングしてください。

`localhost` を使うとデータベース接続が失敗するのはなぜですか?

Takuto は container の中で動くので、localhost の接続文字列はデータベースではなく Takuto 自身を指してしまいます。共有の Docker ネットワーク上で、データベース container の サービス名とその内部ポート を使ってください（例: postgres://…@postgres:5432/…）— localhost やホスト側で公開したポートではありません。CLI を使う場合は、takuto setup で 「このマシンで動作しているデータベース container」 を選べば、これを自動で設定してくれます。外部データベースを参照してください。

GitHub PAT や AI キーの保存が接続エラーで失敗します — トークンが間違っているのですか?

たいていは違います。トークンの検証はプロバイダーのエンドポイント 1 つに到達するだけなので、失敗はほぼ常に認証情報の誤りではなく ネットワーク/egress の問題を指しています — 多くの場合、 api.github.com のような IP がローテーションする CDN 経由のホストが原因です。egress の許可リストがプロバイダーの現在のホストを解決できているか確認し、足りないものは [network] extra_egress_hosts で追加してください。設定 → network を参照してください。

セルフホストモデルが「Model not found」やコンテキストのエラーを返します。

よくある原因は 2 つです: (1) モデルを Takuto が想定する コンテキスト幅 でサーバーにロードする — [agent.providers.opencode] context_limit を、サーバーが実際に提供する値に合わせて設定してください（例えば LM Studio は 32768 ではなく 4096 がデフォルトです）。(2) モデル id はプロバイダーの正確な API 識別子と一致させる 必要があります。セルフホストモデルを参照してください。

Docker ボリュームをリセットしたら、保存した API キーが使えなくなりました。

認証情報は、takuto-data ボリュームに保存されたマスターキー（secret.key）で暗号化されています。そのボリュームを削除または作り直すと、古いマスターキーで封じられたキーはもう復号できなくなります — 症状は、わかりやすい暗号エラーではなく、紛らわしい「authentication」や「not found」のエラーになります。プロバイダー設定を開き直して、各キーを入力し直してください。リセットをまたいでマスターキーを安定させるには、自動生成に頼らず、自分で TAKUTO_SECRET_KEY を用意してください。

起動時にエージェント CLI のインストールが失敗したり壊れたりします — どうすればよいですか?

エージェント CLI（claude / codex / opencode / cursor）は イメージに焼き込まれていません — Takuto は初回の container 起動時にそれらを共有ツールボリュームへインストールし、起動のたびに latest へ更新します。そのため、新しく公開された CLI のリリースが、それまで動いていた環境を壊すことがあります: インストールの失敗、CLI が起動しなくなる、あるいは実行時の挙動の変化です。

これに遭遇したら、CLI を動作確認済みのバージョンに固定 してください。そのプロバイダーのサブテーブルで version を指定すれば、latest の追従をやめます:

[agent.providers.claude]
version = "2.1.178"

これは 4 つすべてのプロバイダー（claude、codex、opencode、cursor）で機能します。再起動すると固定したバージョンがインストールされます。新しいリリースを検証できたら、意図的に固定を引き上げてください。設定 → エージェント CLI のインストールとバージョン固定を参照してください。

コミットや PR は誰の名義になりますか — 私ですか、bot ですか?

帰属はあなたの認証情報に従い、コミットと pull request で同じように扱われます: GitHub PAT を使う場合、どちらも あなた に帰属します。GitHub App だけ（PAT なし）の場合、どちらも bot に帰属します。実行ごとに切り替えるトグルはありません。GitHub App を参照してください。

「Mark as Done」で Jira チケットが動かないのはなぜですか?

Mark as Done はチケットをあなたの [jira] done_status へ遷移させます。これが失敗するのは、Jira プロジェクトの workflow にチケットの現在のステータスからそのステータスへの 遷移がない とき、またはトークンに遷移の権限がないときです。done_status には、ボードの workflow で実際に到達可能なステータスを設定してください。（ステータス名そのものは言語に依存せずに照合されるので、「Terminé(e)」のようなローカライズされた名前でも「Done」に解決されます。）

Takuto を公開ドメインの後ろでホストできますか?

はい。TLS を備えたリバースプロキシの後ろに置き（Takuto Core のインストールを参照）、組み込みのマルチユーザー認証に頼ってください。このログインが入り口であり、Takuto は まだ 2FA/OTP やセキュリティキー（passkeys/WebAuthn）に対応していない ので、すべてのアカウントで 強力でユニークなパスワード を使ってください。組み込みの保護も役立ちます — argon2 によるパスワードハッシュ、失敗の繰り返しによるアカウントロック、ログインの IP ごとのレート制限 — が、今のところパスワードが主たる防衛線です。最後の砦として、ブランチ保護と権限を絞ったトークンも維持してください。

次はどこへ?

初めてですか? まずは クイックスタート から。
チームで運用しますか? Takuto Core のインストール を参照。
挙動を調整しますか? 設定リファレンス にすべてのキーがあります。