Claude Codeは、コードだけを見る道具ではない。 画面録画。 スクショ。 操作メモ。 エラー文。 こういう周辺情報を渡すと、実装の判断が変わる。 初心者は「何を書けばいいか」で止まりやすい。 でも実際には、見えている不具合をそのまま説明すればいい。 どのボタンを押したか。 何を期待したか。 結果がどう違ったか。 文章が下手でも、観察がはっきりしていれば進む。 手がかりが多いほど、原因に近づきやすい。 直す前の景色を渡す。

大きなコードをClaudeに見せれば、問題が勝手に見つかる。 この考え方は危ない。 大事なのは量ではなく、疑う場所を絞ることだ。 最近変えたファイル。 落ちたテスト。 怪しいログ。 再現手順。 この4点を先に渡すと、調査の焦点が合う。 逆に、全部読んでと言うだけでは時間を消費しやすい。 初心者が覚えるべきは、丸投げではなく絞り込み。 質問の入口を狭めるほど、返答は使いやすい。 先に疑いを言語化する。 AIの目は広いが、入口が雑だと迷う。

ClaudeのAPI制限が広がっても、初心者の作業が自動で速くなるわけではない。 回数が増えるほど、雑な依頼も増える。 先に分けるべきなのは用途だ。 軽い確認。 重い生成。 長い分析。 危ない変更。 全部を同じ会話で回すと、どこに時間を使ったか見えない。 制限に余裕がある時ほど、頼む単位を小さくする。 履歴も汚れ、後から見返せない。 上限より先に、使い道の棚を作る。 たくさん動かせる状態は、雑に使っていい合図ではない。

Claude Codeで画面を作ると、何も指定しない限り無難な見た目に寄る。 これは失敗ではない。 AIが判断できる基準を渡されていないだけだ。 色は何色か。 余白は広めか狭めか。 ボタンは角丸か直線か。 一覧は密にするか、ゆったり見せるか。 この条件がないまま作ると、毎回別の見た目になる。 最初に部品の決まりを1枚にする。 迷ったら、好きなサイトを1つだけ参考にする。 作る前に、迷う余地を減らす。 画面づくりは、先に基準。

ObsidianにClaude Codeをつなぐ価値は、メモを読ませることだけではない。 散らばった情報の関係を見える形にできる。 日付。 テーマ。 決定。 未解決。 この4つでノートを整理してから渡すと、AIは単なる検索係ではなくなる。 次に読むべき場所や、抜けている前提まで拾いやすい。 初心者はまず、1フォルダだけ対象にする。 全部渡すより、範囲を決めたほうが判断が鋭くなる。 関係が見えると、次の質問も具体になる。

複数のAIエージェントを同時に動かすと、詰まるのはAI側ではなく管理する人間側だ。 何が進行中か。 どれが停止中か。 誰に次を渡すか。 ここが曖昧なまま増やすと、速くなるどころか確認で疲れる。 最初は2役で十分。 調査する役。 直す役。 それぞれに完了条件を1行で書く。 役割を増やす前に、止まり方を見えるようにする。 次の担当が分かるだけで、待ち時間は作戦になる。 ログも残る。 誰待ちか分かる状態が、次の速度を決める。 並列化は数ではなく、迷子を減らす設計だ。

公式のプロンプトライブラリは、魔法の文章集として読むと外す。 見るべきは言葉ではない。 依頼の分け方だ。 設計。 バグ修正。 コードレビュー。 安全確認。 自動化。 場面ごとに指示が分かれている。 初心者ほど、全部を1回で頼もうとする。 だから返答が長くなり、確認も重くなる。 よく使う依頼を5種類だけ保存する。 使い道が違うものを混ぜない。 これだけで返答の読み方が軽くなる。 型を分けるだけで、再利用もしやすくなる。 プロンプトを増やす前に、場面を分ける。

OpenAIがGeneBench-Proを発表した。 計算生物学で、AIエージェントが曖昧なデータをどう判断するか測るベンチマークだ。 単に正解を当てる話ではない。 どの質問に答えられるか。 どの分析を選ぶか。 途中で前提を直せるか。 ここが見られている。 副業でAIを使う時も同じだ。 答えを急がせるより、判断の道筋を残す。 あとで見返せない結論は、使える知識になりにくい。 AIの仕事は、結論より過程で差がつく。

Claude Codeでつまずく人の多くは、命令が下手なのではなく、起動する場所がバラバラだ。 昨日はDownloads。 今日はDesktop。 明日は古いフォルダ。 この状態だと、AIに見えている世界が毎回変わる。 だから会話も安定しない。 新しい作業は、専用フォルダを作る。 ターミナルで `cd パス` を入れる。 その位置で始める。 これだけで「どのファイルの話か」がズレにくくなる。

Claude Codeの返答が長いとき、全部読もうとして止まることがある。 説明。 候補。 注意点。 次の案。 ありがたいけど、今見るには多すぎる。 そういうときは、先に要約の形を指定する。 今やること。 後で見ること。 無視していいこと。 この3つに分けるだけで、読み方が変わる。 長い返答でも、手が止まりにくい。 全部を同じ重さで読まない。 今必要な部分だけ拾える形にしておく。 先に分ける。 AIの答えは、読む順番まで決めて受け取る。

Claude Codeに任せる作業は、毎回新しく考えなくていい。 よく頼む形は、短いテンプレにしておく。 目的。 対象。 やってほしいこと。 やらないでほしいこと。 返し方。 この5行を残しておくと、次の依頼が速い。 毎回うまく説明しようとして疲れなくなる。 プロンプト集を増やすより、自分の作業用の型を持つ。 毎回ゼロから丁寧に書こうとすると、頼む前に疲れる。 型があると、足りない情報だけ埋めればいい。 頼み方は、使い回すほど楽になる。

Claude Codeで詰まったとき、「もう一回やって」はあまり効かなかった。 同じ前提のまま進むと、似た答えが返ってくる。 先に頼むべきなのは、前提の洗い出しだった。 今どこで止まっているか。 何を正しいと思っているか。 確認していない点は何か。 これを出してもらうと、見落としが見える。 自分では正しいと思い込んでいた条件が、原因だったりする。 作業を続ける前に、地面を確認する。 再実行より、前提確認。 詰まりは手を動かす前にほどけることがある。

Claude Codeで「あと少し」が一番長引くことがある。 色だけ。 文言だけ。 位置だけ。 小さい修正のはずなのに、毎回全体を見直し始めると時間が溶ける。 だから依頼を切る。 今回は文言だけ。 レイアウトは触らない。 ロジックは変えない。 小さい修正ほど、触らない範囲を添える。 これだけで差分が読みやすくなる。 あとで確認する自分も楽になる。 小さな依頼を小さな差分のまま終わらせる。 ここを守る。 微修正は、広げないことが仕事。

Claude Codeに作業を頼むとき、画面名を雑に言うとズレる。 設定画面。 一覧ページ。 編集フォーム。 人間には通じても、プロジェクト内では似た名前がいくつもある。 最近は、依頼にパスを書くようにした。 このファイル。 この関数。 このコンポーネント。 この見出しの下。 場所を言うだけで、余計な探索が減る。 返答も短くなる。 間違った画面を読まれると、その後の提案もズレる。 入口を渡すだけで、会話の精度が上がる。 AIに探させる前に、入口を渡す。

Claude Codeの返答で助かるのは、完成品より「なぜそうしたか」だった。 コードだけ出されると、あとで触れない。 どこが大事か分からない。 次に似た修正が来ても応用できない。 だから最後に一言だけ足してもらう。 変更した理由。 触らなかった理由。 次に見るならどこか。 長い解説はいらない。 判断の跡だけ残ればいい。 次に同じ画面を直すとき、その一言が地図になる。 分からないまま採用する回数を減らせる。 結果より、理由が残ると次も頼みやすい。

Claude Codeで迷ったら、すぐ作らせずに「選択肢」を出してもらう。 A案。 B案。 C案。 それぞれのメリットと、あとで困りそうな点。 最初から1つに決めると、AIの判断に乗るだけになる。 でも候補を並べると、自分で選べる。 非エンジニアでも、比較なら判断しやすい。 細かい実装名が分からなくても、方向性は選べる。 あとで戻しにくい案も、先に見えていれば避けられる。 決める前の整理をAIに任せる。 丸投げより、先に分岐を出す。

Claude Codeに文章を直してもらうとき、いきなり「いい感じに」は頼まない。 先に見本を1つ渡す。 この硬さ。 この改行。 この締め方。 この読者との距離感。 見本がないと、AIは無難な文章に寄りやすい。 きれいだけど、自分の投稿ではなくなる。 初心者ほど、ルールを長く書くより実例を渡した方が早い。 過去の自分の投稿でも、気に入った一段落でもいい。 AIに読ませる材料があると、修正後の違和感が減る。 文体は説明するより、見せた方が伝わる。

Claude Codeにスクショを見せると、UI修正の説明が一気に楽になる。 文章だけだと伝わりにくい。 少し下。 右に寄ってる。 余白が変。 ボタンが近い。 この言い方だと、人間でもズレる。 スクショを渡して、 「このボタンの下の余白だけ見て」 と範囲を指定する。 確認もスクショで返してもらう。 UI修正は、言葉で粘るより見える証拠を渡す方が早い。

Claude CodeでFable自身に使い道をまとめさせた。

Claude Codeで調査を頼むとき、情報を多く集めるほど良いと思いがちだ。 でも本当に欲しいのは、次に動ける結論。 リンク10個。 候補8個。 長い要約。 これを渡されても、初心者は判断に困る。 調査依頼では、最初に返答形式を決める。 結論3行。 根拠3つ。 次に試すこと1つ。 この形にすると、読む時間が減る。 調査の価値は量ではなく、次の一手まで縮めること。