株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
「20分の集中セッション」を起点に、作業に合った長さを考える
AIコーディングエージェントの生産性には、モデルの性能に加えて「セッションの設計」も影響します。方針が固まらないまま実装を進めると、途中の変更で手戻りが増えます。UI改修でも、完成後に方向性の違いが分かると、多くの作業を見直す必要が生じます。まず期待する成果を確認し、途中で見せる単位を決めることが大切です。
明確な指示で小さく作業を区切り、成果を確かめながら進める方法を検討しましょう。Claude Codeの公式ベストプラクティスでも、調査・計画と実装を分ける進め方が紹介されています。本記事では、無駄を減らすための設計術を提案します。20分などの時間や方針変更回数は本記事の運用目安で、特定の実績や生産性の改善率を示すものではありません。作業規模に応じて調整してください。
セッション設計の5つの失敗パターン
失敗1：方針未確定のまま実装に突入する
方針が固まらないまま実装に入ると、配色や構成の修正を繰り返しやすくなります。手戻りを防ぐため、実装前に次の順序で確認しましょう。
実装前に方針を確定する確認手順： 参考デザインを選び、配色・レイアウトの要件を整理する → 複数案が必要なら、まずモックで比較する → 採用する案と今回の変更範囲を確定する → トーンや部品ごとのスタイルを共有する → ボタンなど主要要素の見た目を確認して実装を始める
方針変更が必要になったら、git stash/checkoutなどで作業を切り替える前に、差分と保存先を確認し、残す変更と見直す変更を整理しましょう。
対策：最初にデザインカンプ/モック/参考URL/カラーパレットを確定してから実装を開始する。「まず修正案を全て箇条書きで出して」→ 確定 → 実装指示、の順序を守る。
失敗2：大量の作業が全て破棄される
複数のUI案を検討するときの確認手順： まずモックや比較表で案を絞り込む → worktreeで実装する場合も、先に小さな変更で環境構築と動作確認を試す → 中間成果物を見せ、目的と方向性が合っているか確認する → 大量の実装を始める前に、不要な作業と利用コストを抑える
対策：大きな作業を開始する前に、「この方向性で進めてよいか」の確認を上長に取る。方向性を確認せず長時間作業を続けるのは、タクシーに目的地を伝えずに「とりあえず走って」と言っているのと同じです。
失敗3：曖昧なUI微調整でラリーが膨大になる
「もうちょい太くして」→ 修正 → 「もう一声お願いします」→ 修正 → 「角をつけてカクカクして」→ 修正 → （以下繰り返し）
対策：CSSの数値を直接指定する。「もうちょい」ではなくborder-width: 6px、「カクカクして」ではなくborder-radius: 0。具体的な数値指定で解釈の違いを減らし、変更後の画面を確認して調整します。
失敗4：セキュリティアラートを無視する
危険なコマンドに関するアラートが出たとき、内容を確認せずに許可すると、意図しない変更につながるおそれがあります。表示された操作と対象を確認してから判断しましょう。
対策：セキュリティアラートは毎回確認する習慣をつける。CLAUDE.mdに作業上の注意を明記する。ただし、CLAUDE.mdはモデルに渡す指示であり、操作を強制的に禁止する設定ではありません。禁止対象は権限のdenyルールなどで制御し、必要に応じてPreToolUseフックを使って実行前に判定します。
失敗5：セッションを長時間放置する
表示上のセッション時間には、操作していない時間が含まれる場合があります。経過時間とメッセージ数だけで作業密度を判断せず、実際の変更と成果を確認しましょう。時間が経つだけでコンテキストが劣化するわけではありません。Claude Codeの公式説明では、無関係な会話やファイル内容がコンテキストに蓄積すると性能に影響し得るとされています。長い中断の後は、コードや前提が変わっていないかも確かめます。
対策：使い終わったセッションはこまめに閉じる。Claude Codeで無関係なタスクへ移る際は、必要な決定事項を引き継げる形に整理したうえで/clearを使い、コンテキストをリセットする。
セッション設計の7原則
原則1：方針確定と実装を分離する
1つのセッションで「何を作るか決める」と「実際に作る」を混ぜてはいけません。
| フェーズ | セッション | 目的 | 成果物 |
|---|---|---|---|
| 方針確定 | セッション1（短い） | 何を、なぜ、どう作るかを決める | 方針書or箇条書きリスト |
| 実装 | セッション2（集中） | 確定した方針に基づいて実装 | コード変更+PR |
まず20分程度の集中したセッションで区切り、成果と残作業を確認する進め方が考えられます。ただし、2時間の作業より常に優れるわけではありません。実装・テスト・レビューに必要な時間を含め、タスクに合った区切りを選びます。
原則2：1セッション1方針変更まで
大幅な方針変更が必要になったら、そのセッションを終了して新しいセッションを開始する。旧セッションの古い方針が新しい方針と混在すると、誤った前提を参照するおそれがあります。
原則3：スコープを明示的に宣言する
セッション開始時に「何をやるか」だけでなく「何をやらないか」を明示します。
スコープ：カート機能のみ。 チェックアウトは次のセッション。 決済処理と在庫管理は追加しない。
この宣言により、意図する作業範囲をAIに伝えます。宣言だけで変更範囲が強制されるわけではないため、差分も確認します。
原則4：スペック先行で実装する
コードを書く前に、マークダウンファイルで計画書を作成します。ゴール、受入基準、技術的制約、実装メモを含むスペックをAIに渡してから実装を開始します。
さらに効果的なのはテストファーストです。スペックから先にテストを生成させ、その後に実装させる。AIはテストが通るまで反復するのが得意なため、「全てグリーンになるまで修正して」という指示で高品質なコードが得られます。
原則5：数値で指示する
曖昧な表現は避け、具体的な数値で指示します。例えばmargin-leftは要素の左側の外側余白を設定するプロパティであり、要素を左に移動する指示とは異なります。余白を変えたいのか位置を動かしたいのかも明確にしましょう。
| 悪い指示 | 良い指示 |
|---|---|
| 「もうちょい太くして」 | 「border-width: 6pxにして」 |
| 「左側の余白を広げて」 | 「左側の外側余白を16pxにして（margin-left: 16px）」 |
| 「色が派手すぎる」 | 「#3b82f6から#64748bに変更して」 |
| 「フォントを大きく」 | 「font-size: 18pxにして」 |
原則6：レビュー前にマージしない
AIが生成した変更は、差分を1ファイルずつ確認してからマージします。各セッションの変更は完結し、レビュー済みであること。未レビューのコードが積み上がる状態を避けます。
原則7：セッションのライフサイクルを管理する
- 開始：スコープ宣言 + スペック共有
- 実行：集中して1タスクを完了
- 終了：変更を確認 → コミット → セッションを閉じる
- 次タスク：新しいセッションを開始（Claude Codeでは、必要事項を整理してから
/clearでコンテキストリセット）
セッション品質を測る3つの指標
| 指標 | 理想値 | 警告サイン |
|---|---|---|
| セッション時間 | 20分〜1時間 | 2時間超え → スコープが広すぎる or 方針が定まっていない |
| 方針変更回数 | 0〜1回 | 2回以上 → 新セッションに分割すべき |
| 破棄率 | 0% | 作業が破棄された → 事前確認不足 |
UI作業のセッション設計
UI改修は特にセッション設計が重要です。「見た目」は主観的であるため、方針のブレが発生しやすい領域です。
UI改修の3ステップ
- デザイン確定セッション：参考URL、カラーパレット、コンポーネントライブラリを指定。「まず修正案を全て箇条書きで出して」→ 上長承認
- 実装セッション：承認された案のみを実装。スクリーンショットでBefore/Afterを確認
- 微調整セッション：数値指定（px単位）で微調整。「もうちょい」禁止
複数エージェント環境のセッション管理
Claude CodeとCodexを並行利用する場合、セッション管理がさらに重要になります。
使い分けの原則
- Claude Code：方針確定、コードレビュー、複雑な推論が必要な作業
- Codex：確定した方針に基づく実装、単純なリファクタリング、テスト追加
並列セッションのルール
- 同じファイルを2つのセッションで同時に編集しない
- 各セッションの担当スコープを明確に分ける
- worktreeを使う場合はブランチ命名規則を統一する
コスト意識：セッションのROIを考える
AIエージェントの利用には、作業時間のほか、利用形態に応じた料金や利用枠の消費が伴います。作業を全て破棄すると、実装に費やした資源が成果に結び付かないおそれがあります。途中の学びと再利用できる部分も確認し、完成までの費用と手戻りを抑えましょう。
コストを意識したセッション設計
- 大きな方針判断は人間がセッション外で行う：AIに「どっちがいいと思う？」と聞くのではなく、人間が決めてからAIに実装させる
- 探索フェーズと実装フェーズを分ける：「3案出して」は安いが、「3案全部実装して」は高い。案の選定後に実装セッションを開始する
- チェックポイントを設ける：1時間以上のセッションでは、中間成果物を確認してから続行する
まとめ：セッション設計チェックリスト
| タイミング | チェック項目 |
|---|---|
| セッション開始前 | 方針は確定しているか（上長承認済みか） |
| セッション開始前 | スコープ（やること/やらないこと）を宣言したか |
| セッション開始前 | スペック（ゴール・受入基準・制約）を書いたか |
| セッション中 | 方針変更は1回以内に収まっているか |
| セッション中 | 指示は数値で具体的か（「もうちょい」禁止） |
| セッション中 | セキュリティアラートを確認しているか |
| セッション終了時 | 変更を差分レビューしたか |
| セッション終了時 | セッションを閉じたか（放置しない） |
AIコーディングエージェントは強力なツールですが、セッション設計を誤ると時間とコストが空中分解します。「20分の集中セッション」を一つの目安として試し、成果・テスト・レビューの状況に応じて作業の区切りを調整しましょう。
関連記事
AI開発のご相談はrenueまで。
