コード生成
Themisはあなたの代わりにコードを書くことができます。機能の実装、バグ修正、テスト作成、リファクタリングなど、変更内容をGitHub上のプルリクエストとして提出します。やりたいことを自然な言葉で説明するだけです。
仕組み
- あなたが必要な変更を説明します(チャット、Telegram、またはTeamsで)
- Themisがプロジェクトをクローンし、ブランチを作成して変更を行います
- リント実行、コミット、プッシュを行い、PRを作成します
- あなたがGitHub上でPRをレビューします
すべてのプロセスはバックグラウンドで実行されます。チャットでリアルタイムの進捗状況を確認でき、Themisがコーディングしている間も作業を続けることができます。
コード生成のトリガー方法
チャットから
エージェントに直接依頼します:
「アバターアップロードとタイムゾーン選択機能を備えたユーザープロフィールページを実装して」
「レビューコントローラーのN+1クエリを修正して」
「AutomationSchedulerJobのユニットテストを追加して」
エージェントがコードタスクであることを認識し、生成パイプラインを開始します。
TelegramまたはTeamsから
チャンネルまたはDMでボットにメンションします:
@themis アクティビティフィードにページネーションを実装して
@themis アクティビティフィードの日付フォーマットのバグを修正して
Linearから(Issue割り当て)
Linear issueをThemisボットに割り当てると、自動的に実装を開始します。エンジニアリングチームにとって最も自然なワークフローです。チームメンバーに割り当てるのと同じようにチケットを割り当てるだけです。
- 明確な説明を含むissueをLinearで作成または開きます
- Themisに割り当てます
- Themisがissueのタイトル、説明、リンクされたコンテキストを読み取り、コーディングを開始します
既存のスプリントワークフローとシームレスに連携します。issueをトリアージし、単純なものをThemisに割り当て、戻ってきたPRをレビューしましょう。
オートメーションから
イベントトリガーのオートメーションでもコード生成が可能です。例えば、issueがボットに割り当てられるたびにコード生成をトリガーする、Linear → Issue assigned のオートメーションを設定できます。
表示内容
リアルタイム進捗
チャットに各ステップを示すプログレスバーが表示されます:
Queued → Cloning → Analyzing → Generating → Testing → Linting → Pushing → Creating PR
各ステップは実行中にスピナーが表示され、完了するとチェックマークに変わります。リントで警告が見つかった場合は警告アイコンが表示されます。何か失敗した場合はエラーメッセージが表示されます。
受信トレイ
コード生成は受信トレイの Signals > Code に表示されます。各エントリには以下が含まれます:
- タイトルとプロジェクト名
- ブランチ名と進捗ステータス
- PRリンク(作成後)
- 変更ファイル — 作成、変更、削除されたファイルの数
- AI生成サマリー — 変更内容と動機の説明
- 推論ログ — 展開してエージェントの思考、ツール呼び出し、判断を確認できます
- メタデータ — 所要時間、コスト、コミットメッセージ
既存ブランチでの作業
デフォルトでは、Themisはコード生成ごとに新しいブランチを作成します。既存のブランチで作業するよう依頼することもできます:
「
feat/user-profilesブランチで、登録フォームにメールバリデーションを追加して」
反復的な開発に便利です。最初のリクエストを行い、PRをレビューし、同じブランチでフォローアップの変更を依頼できます。
ブランチ命名規則
ブランチは themis/<type>/<description> の規則に従います:
| タイプ | 使用場面 |
|---|---|
feat | 新機能 |
fix | バグ修正 |
refactor | コードの再構成 |
chore | メンテナンスタスク |
docs | ドキュメント |
test | テストの追加 |
内部の仕組み
分離されたワークツリー
各コード生成は独自のgitワークツリーで実行されます。リポジトリの分離されたコピーです。これにより:
- 作業ツリーとの競合なし。 Themisはあなたのローカルチェックアウトや進行中のブランチに一切触れません。
- 並列生成が安全。 複数のコード生成が異なるブランチで同時に実行でき、互いに干渉しません。
- クリーンな環境。 各ワークツリーはベースブランチの新しいチェックアウトから開始するため、以前の実行の残りの状態によるリスクがありません。
ワークツリーはPR作成後(または生成失敗時)に自動的にクリーンアップされます。
なぜGitHub MCPを使わないのか?
ThemisがGitHub MCPサーバーを使ってAPIでファイルやコミットを作成しないのはなぜか、と思うかもしれません。ワークツリーアプローチは、APIベースのファイル操作よりも意図的に選択されています:
- エージェントが実際の開発環境を使える。 プロジェクト構造全体を読み、ツールを実行し、インポートを確認し、コンテキストを理解できます。APIを通じて盲目的にファイルを作成するだけではありません。
- 標準的なgitワークフロー。 変更は
git add、git commit、git pushを経て行われます。開発者が使うのと同じフローです。これにより、適切なdiff、blame履歴、マージ動作が保証されます。 - セキュリティサンドボックス。 エージェントは制御されたシェルアクセスを持つサンドボックス環境内で実行されます。危険な操作(ワークツリー外のファイル削除、権限昇格、シークレットアクセス)はセキュリティフックによってブロックされます。
- スキルの発見。 エージェントはコードを1行書く前に、プロジェクトの
.claude/ディレクトリ、CLAUDE.md、スキルファイルを読んで規約を理解します。
エージェントのセキュリティ
コード生成中、エージェントは厳格な制約の下で動作します:
- パスの制限 — ワークツリーディレクトリ内のファイルのみ変更可能
- git操作の禁止 — ブランチ作成、コミット、プッシュはジョブが処理し、エージェントは行いません
- ブロックされるコマンド —
rm -rf、chmod、外部ホストへのcurl、環境変数アクセスなどの危険な操作は遮断されます - サンドボックス実行 — 本番環境(Docker)ではコンテナが追加の分離を提供し、ローカルでは
bwrapがファイルシステムアクセスを制限します
プロジェクトスキル
プロジェクトに .claude/ ディレクトリとスキル(コーディング規約、アーキテクチャガイド、テストパターンなど)がある場合、Themisは自動的にそれらを検出して読み込みます。エージェントは以下を読み取ります:
CLAUDE.md— プロジェクトレベルの指示、技術スタック、規約.claude/skills/— 専門的な知識ファイル(テストパターン、Hotwire規約など)- ポータブルスキル —
lib/skills/のプロジェクト横断スキルがワークツリーにコピーされ、エージェントが使用します
これにより、生成されるコードはジェネリックなボイラープレートではなく、プロジェクト固有のパターンに従うことが保証されます。
ヒント
要件を具体的に。 「検索機能を追加」では曖昧です。「pg_trgramを使用して会話インデックスページに全文検索を追加し、デバウンス入力用のStimulusコントローラーを使用」とすると、はるかに良い結果が得られます。
生成されたコードが期待と合わない場合は、推論ログを確認してください。エージェントが何を理解し、なぜ特定の判断をしたかが正確に表示されます。
複雑な機能は同じブランチで反復しましょう。コア実装から始め、レビューし、改善を依頼します。各フォローアップは前回の変更の上に構築されます。
ステータスリファレンス
| ステータス | 意味 |
|---|---|
| Pending | 処理待ちのキュー |
| Cloning | gitワークツリーのセットアップ |
| Analyzing | プロジェクトのコンテキストとスキルの読み取り |
| Generating | コード変更の作成 |
| Testing | テストの実行(設定済みの場合) |
| Linting | コードスタイルのチェック |
| Pushing | コミットとリモートへのプッシュ |
| Creating PR | GitHub上でプルリクエストを作成 |
| Completed | PRが正常に作成されました |
| No Changes | エージェントがコード変更は不要と判断しました |
| Failed | エラーが発生しました — エラーメッセージを確認してください |