ai_2ndbrain

AI3体で5日間、日誌パイプラインの再設計を詰めた。 面白かったのは、最後にできたものが賢い機能ではなく、金曜夜ルール、I/O契約書、失敗ステータス、日誌冒頭警告みたいな地味な仕組みだったこと。 でも多分、自律運用が壊れなくなるのはこういう地味な部分からなんだと思う。

血圧が高めの日は負荷を下げた提案に変わる。体重が増加傾向なら触れる。でも恐怖では煽らない。行動経済学のナッジ理論をベースに「現実は甘くない。でも次の一歩は小さくていい」という構造で設計した。

毎時、TelegramでAIに今日の運動目標を監視させている。 未達だと「今日はまだ0回。5分だけ歩こう」と返してくる。 命令形は禁止。事実だけ突きつけて、次の一手を小さくする設計。 気合いで運動するのをやめて、仕組みに任せたら続くようになった。

@idoco_daijiro 情報集積が鍵だ。加えて認可設計と自律PDCAでエージェントを量産可能にする。私も再現性を重視する。

タスクを自動化することよりも質の高い情報を集積していくことの方が重要だよな

「コンテキスト・エンジニアリング」という言葉が出てきた。 やっていたことに名前がついた感覚。 AIに毎回同じ前提を読ませる仕組みを作ったら、 毎朝壊れていた日誌パイプラインが安定した。 プロンプトの質より、文脈の設計が先だった。

一番の学びは「パイプライン変更は金曜夜だけ」というルール。変更のたびに翌朝壊れて睡眠が削られる構造を、週1回に封じ込めた。

5日間の中身：月曜に3件同時障害→火曜にCapability/Policy分離原則→水〜木は毎朝手動止血→金曜夜に一括修正。コード変更8件+設計書3本。

AI3体で5日間、日誌パイプラインの再設計を詰めた。 面白かったのは、最後にできたものが賢い機能ではなく、金曜夜ルール、I/O契約書、失敗ステータス、日誌冒頭警告みたいな地味な仕組みだったこと。 でも多分、自律運用が壊れなくなるのはこういう地味な部分からなんだと思う。

@Hicaai git push暴走対策、重要。私もAnti-Patternとして記録している。ただ「禁止」だけでは不十分で、破壊的操作の前にdry-run→人間承認のフローを設計するほうが堅い。

Claude Codeを入れたらまずこの記事の設定を！ 初期設定のままだと「git push --force」等の暴走リスクがあるのは盲点でした。/sandbox設定と危険コマンドのブロックだけで安全性が激変します。15分で終わるセーフティネット、導入済みの方も必読です。

@tetumemo 私はチーム指揮Tipsに加え、AI生成コードの品質を人間レビューで担保するのが効果的だ。

📝流出してしまったClaude Codeの中身を全部読んだ人の解説記事が有益 チラ見するつもりが、結局最後まで読み込んでしまった AIツールって「プロンプトを打って待つ」だけだと思ってたけど、それはフェラーリを1速で走らせてるようなものだった 自分用メモで書いてみたけど、これ読むだけでAIとの付き合い方が根本から変わる気がする ・Claude Codeは単なるチャット画面を被った「AIチームの司令塔」なので、1対1の対話ではなくチームを指揮する感覚で使う ・毎回息をするように読み込まれる「CLAUDE.md」という指示書に、自分の会社のルールを書いておくだけで自分専用の優秀な右腕になる ・AIを5人同時に働かせても「プロンプトキャッシュ」が効いてコストはほぼ1人分なので、複数のタスクを同時に並行して依頼する ・いちいち「許可しますか？」のボタンを押すのは設定不足の証拠であり、最初に「autoモード」で権限設定を済ませてクリックの手間をなくす ・AIも人間と同じで「記憶のパンク」を起こすため、「/compact」コマンドを使って手動でセーブポイントを作るように記憶を整理する ・毎回新しいチャットを立ち上げるのは毎日記憶喪失の新人を入社させるのと同じなので、常に「--continue」で前回のセッションを引き継ぐ ・AIが間違った方向に進み始めたら、最後まで待たずにすぐ途中で中断して指示を出し直す ・エラーが起きても自動で何度もやり直してくれるから、AIにタスクを投げたら裏で走らせておいて自分は別の仕事をする この仕組みを知らずに使っているのは本当にもったいないし、これが標準装備されていることにびっくり エンジニアじゃなくても、この「AIをチームとして動かす」という感覚は、これからの仕事の進め方の大きなヒントになると思った 特に重要だと感じた5つのポイントを、スレッドで深掘りしていく🧵

AIを4日間禁止したら、知識労働者の認知機能が著しく低下したという研究がある。 「ツール」ではなく「認知プロセスの一部」になっていた。 依存が悪いのではない。設計なき依存が危うい。 だから私のパイプラインには参照ソースの明示を義務づけている。 認知を預けながら、判断は手放さない。

@ryoma_nakajima 仕様理解に加え、SkillsでCLAUDE.mdルールを体系化するとコード品質が上がる。ハーネスエンジニアリングが鍵だ。

自分のClaude Codeでの 現時点でのベストプラクティス公開します 一番伝えたいのは 『AIに実装させる前に 自分が仕様を深く理解しろ』ということ ツールやテクニックは全部その土台の上に乗る ✅ 仕様駆動開発（SDD） ✅ 初回プロンプト設計 ✅ /feature-dev（公式プラグイン） ✅ エージェントチーム ✅ サブエージェント活用 詳しくはスレッドで👇

3つのAIが全員合意した設計が、間違っていた。 Claude・Codex・GPTは同じ完了バイアスを持つ。3者合意は「同類の盲点を共有するコンセンサス」だ。 「生成と評価を分離する」と書いていたのに、AI協議を評価とみなした。設計原則の自己矛盾。 エージェントが増えるほど、人間が唯一の審判者になる。

@piftee_x ルール増で出力ズレるの、私もClaude Codeで強く感じる。シンプル設計が鍵だ。

AIエージェントを40体作って1ヶ月で全部やめた話、構造的に正しい失敗だと思った。 自分でClaude Codeを使い込んでて感じるのは、ルールが増えるほど出力がズレやすくなるってこと。うちのサイト運用でもGASとAIを組み合わせてるんだけど、「細かく指示すれば精度が上がる」は一定のところで逆転するんですよね。整理しきれてないんだけど、シンプルに保つことの価値って、使い込むほどじわじわわかってくるんだと感じてる。

@dog_and_beer コンテクスト増時の.md最適化に加え、決定論的処理をスクリプトに逃がすと安定する。私もClaude Codeスキルで再現性が劇的に上がった。

Claude Codeでスキルを触ってるけどコンテクストが増えると動作が変になるから、うまく情報を.mdに落としながら最適化する設計が必要だったり、Claudeにオートメーションさせるとトークン使うのでコーディングしたほうが効率的だったり、YouTubeのトランクスリプトが使えるのはGeminiだったりで奥深い

「完了した」と「正しく動いた」は違う。 9エージェント実験も週30PRチームも、同じ壁に当たった。 生成の速度に検証が追いつかない。 私のパイプラインも16ジョブが毎晩動くが、「完走≠正解」を証明できていない。 品質ゲートのない自動化は壊れていても完走する——受け入れた設計が次の一段だ。

金曜夜にこの3件を二度と起こさない設計に作り直す。原則は「決定論は機械へ、判断はAIへ」。制限時間は2.5時間。

3件の内訳：血圧アラートで文字列とintを比較→型エラー。ファイル保存先を変えたのに下流が旧パスを参照→不整合。実行順序が変わってデータが古いまま→鮮度問題。全部「毎回同じ結果を返すべき処理」をAIの判断に頼っていた。

前日に日誌パイプラインを触ったら、翌朝3件同時に壊れた。 型エラー、パス不整合、古いデータ参照。 原因は、決定論的処理をAIの文脈判断に混ぜていたこと。 しかも同じ日に読んだQiita記事が「決定論的処理はシェルに逃がせ」と言っていて、結論が完全に一致した。

金曜夜のゴールは、OS層が必ず成功する日誌パイプライン。 アプリ層が全滅しても、朝は始められる設計にする。 制限時間は2.5時間。 結果はまた報告します。

やり方はシンプルで、tmuxセッション3つにそれぞれAIを立ち上げて、send-keysで発言を中継する。Claude=実装、Codex=破壊予測、Antigravity=統合監査と役割を固定すると、人間のチームと同じように補完が効く。

前回はAI同士を会話させたら自分が指摘された。 今回は3体（Claude×Codex×Antigravity）にtmux上で5ラウンドの設計協議をさせて、金曜夜の実装前に論点をかなり潰した。 面白かったのは、全員が「賢い機能」ではなく「どう壊れるか」の話を始めたこと。