Takumi👻

[Takumi👻 @app_tkm]

費用の内訳、月別推移、フック型別の集計、失敗の考察まで全データをnoteにまとめました👇
https://t.co/g6P4c2leqy

[Takumi👻 @app_tkm]

4ヶ月間、XのアカウントをAIに丸投げして自動運用した結果。

投稿数: 199件(毎日自動)
費用: 約500円
総インプ: 21,627
平均インプ: 109/投稿
いいね: 117
獲得フォロワー: 50人

計測→学習→改善まで全自動で回して、これです。

何が伸びてなぜダメだったのか、全データはリプに👇

[Takumi👻 @app_tkm]

唯一はっきり効果があった改善は投稿方式の変更。

・ニュース紹介+リンク: 平均56インプ
・実体験風オリジナル(リンクなし): 平均126インプ

2.3倍の差。外部リンク付きは伸びない、「紹介」より「体験」が読まれる。

伸びた投稿の上位は全部「お金の話×実体験」でした。

[Takumi👻 @app_tkm]

ただし、音声認識の精度は Opus > Sonnet > Haikuで結構差がある。Haikuで敬語や数字が混じると誤認識率跳ね上がる。返信内容によってモデル切り替えてる。あと句読点が自動で入らないから、「改行」「句点」みたいに明示的に言う手間が地味に増える。

[Takumi👻 @app_tkm]

昨日、Claude の音声モードでメール返信してたら、テキストより 5 倍速で片付いた。マジで驚いた。

これまで Haikuだけだったけど、今週から Opus と Sonnet も選べるようになった。Gmail や Slack も音声で直接操作できる。つまり「メール読み上げてもらう→話しかけて返信作成→そのまま送信」が手元で完結する。

マウス・キーボード一切使わない状態で朝のメールチェックを10分で片付けるのは、正直別世界。Notion のタスク確認も「タスク一覧読んで」って言うだけで、音声で追記できる。Canva との連携は試してないけど、デザイン指示も音声でいけるって聞いた。

通勤時間や飯食いながら「ちょっと返信」が本当にできる。テキスト入力する身体が一切要らない。

#LLM #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

ちなみに11個のskillセットを作るまでに、最初は「これ本当に繰り返されるのか」って疑問に何回もぶち当たった。実装3つ分やってみて初めて「あ、毎回同じ順序だ」って気づく感じ。急いでテンプレート化するより、まず3周目で「あ、パターンだ」って観察するフェーズが地味に大事。

[Takumi👻 @app_tkm]

昨日、Claude Code で同じプロジェクトを何度も立ち上げるたびに「あ、前回どこまで進めたっけ」って context を一から説明し直してた。馬鹿らしくなった。

気づいたのは、繰り返しのタスク設計を skill 化できるってこと。「プロジェクト構成を把握する」「実装タスクを3つに分解する」「ドキュメントと実装を同期する」みたいな一連の流れを、Claude Code の指示テンプレートに固めちゃう。

最初は skill と呼ぶのは大げさだと思ってたけど、実際やってみたら 11 個ぐらい共通パターンが出てくる。プロジェクト立ち上げのたび「OK、いつもの skill 入れて」と prompt の先頭に流し込むだけで、同じ説明を繰り返さなくていい。コンテキスト枠も節約できる。新規プロジェクトでも、古いプロジェクトに戻るときも、セッション跨ぎも全部同じ skill セットを回せば、Claude Code の動作が安定する。

正直、手で何度も同じワークフロー説明を打つ時代は終わってる。

#ClaudeCode #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

補足。Q4_K_M で動かすときは `OLLAMA_NUM_GPU=1` を明示的に指定しないと CPU フォールバックして爆遅になる。環境変数設定忘れて「4GB じゃ無理」と勘違いしてた。

[Takumi👻 @app_tkm]

昨日、VRAM 4GB のノートPC で Ollama を動かして、ローカル LLM の限界がどこまでなのか試した。結果、思ってたより実用的だった。

環境は Windows / Ollama 0.32.1 で GPU は RTX 3050 Ti（VRAM 4GB）。重いモデルを無理に載せると VRAM が吹っ飛ぶから、ここが勝負。Phi-4 や Mistral 7B みたいな軽量モデルなら、メモリ圧迫なしに会話が続く。

正直、4GB で動く LLM って「会話できるレベル」には全然到達できないと思ってたんだけど、量子化モデル（Q4_K_M 形式）に絞ると話が変わる。レスポンスは 1〜2秒遅延するけど、会話の質は実務レベル。コード補完の下書きレベルなら 3050 Ti でも十分。

ただし同時に 2 つ以上のタスクを回すと即詰む。Ollama で会話させてる最中に別プロセスを立ち上げると、メモリが足りずプロセスが落ちる。ここが 4GB の現実。つまり「メイン作業 + 補助的な LLM」という使い方は諦めて、一点集中で動かす設計じゃないと無理。

同じスペックでローカル RAG を組むなら、embedding モデルを軽くする必要がある。ONNX 版の小型embedding（BGE-small-ja とか）で何十万トークン保持できるか試してみたら、意外とぶん回った。ただし大量クエリを同時に投げるとやっぱり落ちる。

PC が限界に達するのは「メモリ管理を甘く見たとき」だ。

#ローカルLLM #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

補足。実装してて気づいたのが、schema を渡しても最初の1〜2回は無視されることが多いので、システムプロンプトで「絶対に JSON のみを返す」と3回くらい強調しとくといい。あと出力サイズが大きいと途中で切れる。

[Takumi👻 @app_tkm]

昨日、手元の Mac で Ollama を使ってニュース自動収集 bot を作ってて、LLM に JSON を返させたら全くパースできない形で返ってきた。JSON のはずが、「あ、これ解析不能」みたいなテキストまで混じってた。

犯人は簡単だった。Ollama に「JSON で返せ」と日本語で指示しても、モデルがそれを厳密に守らない。出力にあたるまえに、`.json` ファイルスキーマを JSON Schema 形式で渡す必要がある。

`ollama generate --model llama2 "ニュース3件をこのスキーマで返す: {\"type\": \"object\", \"properties\": {\"title\": {\"type\": \"string\"}}}"` みたいに、期待する構造をあらかじめモデルに教えておく。すると返ってくるテキストがほぼ必ず JSON 形式になる。正規表現で後処理する手間が消える。

2日前は Python で無理やり JSON.parse を try-catch で括ってたけど、今は Ollama 側で構造を固める。ローカル LLM でも「適当に返す」じゃなく、スキーマに従わせる仕組みを入れるだけで、パイプラインの安定性が段違い。

#ローカルLLM #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

実装時の注意点として、生成スクリプトは pre-commit で走らせるより pre-push がおすすめ。ローカルの試行錯誤中に毎回ファイルが上書きされるとストレス。あと AGENTS.md を YAML にしておくと、別言語のツール（Node やシェルスクリプト）からも読み込みやすくなる。

[Takumi👻 @app_tkm]

昨日、Claude Code と Cursor を同じプロジェクトで並行して動かしてたら、気づいた。ルールファイルの管理が地獄になってた。

CLAUDE.md が1個、.cursor/rules/project.mdc が別、.github/copilot-instructions.md がさらに別。3つ全部に同じ内容を手で書き足してる。誰かが CLAUDE.md だけ更新して、Cursor 側は古いルールのままとか、平気で起きる。

それ以来、リポジトリのルートに AGENTS.md を1個だけ置いて、そこから全部生成する形に切り替えた。AGENTS.md に書いたルール定義を Python で読み込んで、Claude 用・Cursor 用・Copilot 用の3つのファイルを自動生成するスクリプトを git hooks に仕込む。更新は AGENTS.md だけ。3つのエージェントに常に同じルールが配信される。

複数の AI エージェントを本気で使うなら、ルールの単一ソース化は必須。ファイルを手で sync してる限り、いつかズレる。

#ClaudeCode #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

補足。ルールセットを JSON で定義するときは、正規表現よりも「危険なパターン」を具体例で箇条書きした方が Copilot の出力ぶれが少ない。うちは XSS チェックで正規表現 10 個書いてたけど、具体例 30 個に変えたら生成テストの一致率が 60% から 92% に跳ねた。

[Takumi👻 @app_tkm]

昨日、GitHub Copilot でセキュリティテストのコード生成をぶん回してたら、同じ脆弱性チェックを何度も書き直させてることに気づいた。

正直、「AI に任せたら自動化できる」と思ってたけど、実際は違った。生成させたテストコードが毎回微妙に違うし、カバレッジにムラがある。同じセキュリティルールを何十回も「こういう危険なパターンをチェックして」と説明するハメになる。

そこで試したのが、テンプレート化。自分たちのセキュリティ基準を JSON で定義しておいて、Copilot に「このルールセットに基づいてテスト書いて」と渡す。すると生成されるコードの品質が一気に安定する。SQL インジェクション検出、XSS チェック、認可ロジックの検証——全部が統一された基準で動く。

先週、これをチーム内で試してみたら、レビュー時間が3分の1に縮った。AI が同じ基準に沿ってコード書くから、「なぜこの書き方？」という無駄な質問が消える。

AI にセキュリティテストを任せるなら、ルール定義を先に人間がやる。そこが揺るがなければ、AI のアウトプットは本当に使い物になる。

#ClaudeCode #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

ちなみに Claude Code は staged/unstaged の区別を理解してないことがあるので、こちらから `git add` で明示的にステージングさせてから commit させる方が確実。さもないと `.env` とか本来コミットされちゃいけないファイルまで一緒に上げられたことがある。

[Takumi👻 @app_tkm]

昨日、Claude Code で Git コマンドを丸投げしてたら、意図した履歴が残らずに何度も同じコミットを作り直させた。犯人は「どのタイミングで commit させるか」をちゃんと指示してなかったこと。

AI に任せるなら、Git の操作を「確定的」に流す方法が必須。たとえば `git add . && git commit -m "feature: ..."` を1つの単位として依頼するか、あらかじめ `.gitignore` で不要ファイルを除外しておくか、そもそも rebase を禁止にするか。曖昧なまま「コード書いといて」と言うと、AI が勝手に git reset --hard して履歴をリセットしたりする。

正直、AI にできるだけ細かく「このコミットメッセージを使え」「このブランチだけ作成しろ」と指定する方が、後でレビューするのが楽。セッション中に何度も修正させるくらいなら、最初に Git の操作フローだけ自分で決めて、その枠の中でコード生成させた方が早い。

Git の操作ルールを決めてから AI に任せるのが、結局一番 commit 履歴がきれいに残る。

#ClaudeCode #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

実は 1 段目の「動作確認」で意外と引っかかる。エッジケース（空配列、null、負の数）を 3 つくらい手入力で試すだけで、同じバグの再発が 70% 減った。AI は happy path しか見てないから。

[Takumi👻 @app_tkm]

昨日、Claude Code で毎日量産させたコードをレビューしてたら、気づいた。「何日も前に AI が書いた箇所で同じバグが出てる」を何度も繰り返してた。

レビューの漏れじゃなくて、レビューの「粒度」が雑だったんだ。AI が一気に 100 行書いたら、全部を同じ目線で見てた。正直、それじゃ追いつかない。

だから段階分けを決めた。1段目は動作確認だけ（実際に手元で動かす）。2段目はセキュリティ周り（入出力バリデーション、API キー扱い）。3段目は論理バグ（条件分岐、ループ終了条件）。4段目は冗長性（同じ処理の重複、削れる変数）。毎回全部やらない。

AI が書いた量が多いほど、この分割を甘く見ちゃう。「全部見なきゃ」という思い込みが、むしろ落としどころを増やしてた。先週、プロジェクトの新機能 5 個を同じ感度でレビューしようとしたとき、3 個目で集中切れてた。

レビューの「安心感がない」のは、レビュー漏れじゃなくて、1 回のレビューで見ようとしてることが多すぎるせい。4 段検証に絞ったら、2 日後に出てくる「あ、ここバグだった」が 8 割減った。

#ClaudeCode #エンジニアと繋がりたい

[Takumi👻 @app_tkm]

実際やってみて気づいたのは、AI への指示を細切れにしすぎるのも逆効果ということ。「このステップだけ」と限定しすぎると、今度は文脈がなくて妙な判断をされる。結局、自分が「ここまでは確定、ここからは変動」という判断ラインを引いて、変動部分だけのコンテキストを渡すバランスが一番プロンプト短くなった。

[Takumi👻 @app_tkm]

昨日、Claude Code で同じファイルを何度も修正させてたら、プロンプトが段々長くなってることに気づいた。最初は「この部分を直して」だったのに、気づいたら「前回の変更のこの部分は実は〜だったから、それを踏まえて〜」みたいに説明が増えてた。

原因は単純。毎回 AI に「全部から判断させてる」からだった。人間が「このループはもう安定したから、次は検証ロジックだけ直す」みたいに意思決定して、その狭い範囲だけ AI に指示すれば、プロンプトは短いまま。でも自分は「AI に全部見直させて」という甘い期待をしてたから、毎回全体のコンテキストを説明する羽目になってた。

先週、新しいプロジェクトで試したのが「ループを分ける」という発想。生成 → 検証 → 修正のサイクルを最初から設計して、各ステップで Claude に渡す指示を「このステップだけやってくれ」と限定した。そしたら AI も人間も判断が早くなって、プロンプトは短いまま、セッションが安定した。

「AI にプロンプトを打つ」じゃなくて「ループそのものを設計する」に切り替えた瞬間、開発の質感が変わる。

#ClaudeCode #エンジニアと繋がりたい