目次8 セクション
2026年9月時点の資料に基づくガイドです。料金、モデル、画面の名称は変更される場合があります。リアルタイムの製品情報ではありません。
毎回の指示を仕様書にせず、役立つプロジェクト制約を渡します。
検証できるルールを書く
検証コマンド、重要なソースディレクトリ、少数の設計制約から始めます。「既存のフォーム検証関数を使う」は「きれいなコードを書く」より実行しやすい指示です。これは記述上の提案で、ファイル名や適用条件はツールごとに異なります。
最初の指示例
リポジトリに合わせて例を編集し、ツールの公式ルール／指示機能から保存します。
Before editing, inspect the nearest existing implementation.
Use the package manager already configured in this repository.
Run the relevant checks for changed behavior.
Report any check you could not run and why.
Do not edit generated output directly.ルールが適用されるか確認
指示によって観察可能な行動が変わる小さなタスクを試します。結果とコマンドを確認し、無関係な作業にも反応するなら範囲を狭めます。ルールもビルド手順と同様にリポジトリと一緒に見直します。
最初の実作業：変更、検証、レビュー
-
すでにビルドできる小さなリポジトリを選び、Gitで作業前の状態を保存します。現在成功する検証コマンドを記録して基準にします。
-
既存フォームへの必須項目追加など、観察可能な結果を一つ指定します。対象ファイル、既存の検証処理、維持すべき動作も伝えます。
-
編集前に短い計画を確認し、影響するコンポーネント、データの流れ、検証方法を確かめます。不足する文脈を埋めてから実装に進みます。
-
差分を少しずつ確認し、依存関係、生成ファイル、環境変数、例外処理も点検します。正常系と異常系の両方を試します。
-
完了後に利用量とレビュー時間を記録します。別の代表的タスクでも試してから、有料プランやチーム移行を判断します。
調整して使えるタスク説明
目標：利用者から見える変更。
文脈：対象ファイルと既存実装。
制約：公開APIと既存依存関係を維持。
検証：プロジェクトのチェックと異常系。
完了条件：変更ファイル、実行した検証、残る制限を報告。結果が使えない場合の切り分け
応答の成功とコードの正しさは別です。違うファイルを変更したら範囲と入口を明示します。コマンドが失敗したら同じ端末環境で再現します。MCPは起動、認証、クライアント設定を分けて調べます。利用上限に達したら残量とモデルを確認します。無関係な変更を失わず戻せる大きさに差分を保ちます。
移行前によくある質問
有料プランならエージェントを無制限に使えますか？
いいえ。月額、含まれる利用量、モデル権限、追加利用料は別です。補完が無制限でもモデル要求が無制限とは限りません。
MCPを最初から全部接続しますか？
現在のタスクに必要な一つから始め、起動、ツール、渡す文脈を確認して順に追加します。
エディタを公平に比較するには？
同じリポジトリ、タスク、検証基準で、正しい変更、レビュー負担、設定の手間、実際の利用量を比べます。
TRAEの関連記事
続きを読む
同じテーマやツールに関連する記事。
