ブログ
pdlc-skills は進捗・変更の影響・品質の傾向をどう見せるのか
AI は午後のあいだに三つの機能を進めます。いまどこまで進んだのか、ここを直すと何に波及するのか、この一か月はどうだったのか。それが見えなければ、自動化はブラックボックスの中で回っているのと同じです。pdlc には同じ状態ファイルを読む三つの道具があります。ステータスラインと /pdlc-status で「いま」...
pdlc-skills は AI に書かせたコードの品質をどう守るのか
AI でコードを書く速度は上がりました。しかし「そのコードが正しいか」を判断する速度は上がっていません。この差そのものがリスクです。だから AI 支援開発では、品質保証は速度の足を引っ張る負担ではなく、速度を使い物にするための前提になります。この記事では、私が pdlc で使っている七つの環をつないだ一本の鎖を、...
pdlc-skills はどうやって無人で回すのか
一つの機能なら、コマンド一本で TDD・実装・レビューまで自分で走り切ります。スクリプトが要るのはその外側——十数個の機能点を依存関係でバッチに分け、一バッチ終わるごとに人が確認してから次を起動する。支えているのは四つのガードレールで、どれも実際に作動する場面を見ています。
pdlc-skills を自分のプロジェクトで動かすには
入れるのは一行で済みます。本当に詰まるのはその次の一歩——新規プロジェクトか、既存のコードベースか、すでに導入済みかで、最初のコマンドがまったく違います。そして飛ばされがちな一手があります。それを飛ばすと、前回の「客観的な停止判定」はモデルの自己満足に丸ごと退化します。
三大エンジニアリングは pdlc-skills の中でどう噛み合うのか
三層は最初から最後まで一度も互いを呼び出しません。ディスク上の一つのファイルを介して引き継ぐだけです。そしてそのファイルが機能ごとに分かれているおかげで、このパイプラインは縦に一本走るだけでなく、横に広げて何本も同時に走らせられます。
なぜ pdlc-skills は三大エンジニアリングに自然と噛み合うのか
この三層は私が設計して入れたものではありません。作っていた当時、Loop エンジニアリングも Graph エンジニアリングという言葉も聞いたことがありませんでした。ソフトウェア工学に何十年も前からある製品開発ライフサイクル——要件、設計、テスト、実装、レビュー——をそのままなぞっただけです。作り終えてから三大エン...
プロンプトエンジニアリング・Loop エンジニアリング・Graph エンジニアリングとは何か
この三つの言葉は最近いつも同じ比較表に並べられ、まるで三択のように扱われています。しかし三者はそもそも同じ階層にいません。プロンプトは一回のやり取りを、Loop は反復の収束を、Graph は経路そのものを決めます。この違いを理解することは、どれか一つを習得することより価値があります。
AI の記憶に「健康診断」ツールを作った——診断はするが、手は出さない
前回は AI の記憶ライブラリを手作業で「除草」し、最後にこう悟った——雑草が繰り返し生えるのは、記憶システム自体に「自己点検」の仕組みがないからだ。そこで今回は、その健康診断をツールにした。医者のように、スキャンして問題を並べ、そこで止まる——直すかどうかは、いつもあなた次第。外部の大規模モデルには一切つながず...
AI の記憶にも雑草は生える——こまめな手入れが要る
前回は AI に記憶の仕組みをどう構築するかを話した。だが構築は始まりにすぎない——プロジェクトが長引くほど記憶は積み上がり、手入れを怠ると、そこに静かに「雑草」が生えてくる。今回は自分の複数プロジェクトの AI 記憶を体系的に「除草」し、記憶が劣化する六つの典型パターンを整理した。最も危険なのは、AI が期限切...
AI に「あなたをわかってもらう」には——記憶の仕組みを強化する
同じ AI に、同じ場所で何度もつまずく——使うなと言った旧構文をまた書き、決めたルールをすぐ忘れる。バカなのではなく、そもそも記憶がないだけだ。今回は人の脳になぞらえて考える：なぜ良い記憶は「積み上げ」ではなく「構造」なのか、なぜ誤りの修正は追記ではなく上書きなのか、そして一番きれいごとでない一点——覚えていて...
AI の「オオカミ少年」、信じるべきか？——本当に「悪意あるプロンプト」を感じた誤報
作業の途中で AI が手を止めて言った：「まずセキュリティ警告を出させてください」——あるコマンドの出力に、私のユーザー名を外部に送り出す injection が紛れている、と。私は即座に信じ、30 分ほど一緒に追いかけた。後で振り返ると、これは誤報だった——攻撃は AI が脳内で作り出したものだった。それでも信...
AI が作業を終えたのに、疲れているのは私だ——あなたはその「司令塔」
ここ数回はずっと、AI にもっと多く・もっと並列で働かせる話だった——トークン節約、モデル階層化、複数 agent のオーケストレーション、worktree。今回は毛色が違う：AI を満杯まで推し進めたら、疲れていたのは私自身だった。一人で別々の役割の AI チームを率いて効率を十数倍にできる——だがその代償とし...
AI を並列で動かす前提は、独立した作業領域を切り分けること
前回は並列の話だった——大きなタスクを分割し、複数の agent に同時にばらまく。だが尻尾を一つ残していた：複数の手が同じコードを同時に触るとき、何が衝突を防ぐのか？その答えがこれ。最初は素直にリポジトリを 2 つ clone してディスクで痛い目を見て、その後 git worktree に切り替えた。直感に反...
AI の作業が遅い？モデルが鈍いんじゃない、一つずつやらせているだけかもしれない
前回は AI に「より安く」作業させる話だった。今回は「より速く」——大きなタスクを、AI に一モジュールずつ順番に片づけさせるのではなく、分割して複数の agent に同時にばらまく。直感に反するポイントは、並列にしてもトークンはほとんど節約できないということ。節約できるのは時間だ。
AI が会話を重ねるほど馬鹿になる？モデルのせいじゃない、そろそろ手を打つ番だ
前の二回は「コンテキストに入る前」にトークンを節約する話だった。今回は会話の最中にやる二つのこと——誰が作業するか（モデル階層化）と、どれだけ記憶を抱えて作業するか（コンテキスト管理）。AI が途中から鈍くなるのは、たいていモデルのせいではない。
AI コーディングが高くつく？トークンを 82% 削った（実測データ付き）
前回はツールを正しく使う話だった。では具体的にどう？今回は実数付きの実践編——rtk gain は六千以上のコマンドで 740 万トークン、82% を節約していた。
トークンを食っているのはドキュメントではない、ツールの使い方だ
PDLC はドキュメントだらけでトークンを食う？——ドキュメントが多いこととトークンを食うことは別の話。本当に節約したいなら、ツールを正しく使うことであって、ドキュメントを削ることではない。
PDLC 1.1：v1.0 が成果物の形について犯した2つの間違い
v1.0 は縦方向の問題を解決しました——feature のステージを順序よく進めること。v1.1 は2つの横方向の問題を修正します：成果物タイプの混在と、feature 間の関係欠如。
aitm 1.0：AIをコパイロットに、ハンドルは自分で
aitm 1.0 リリース。バイナリ 5.3MB、コールドスタート 3-5ms、6つのLLMプロバイダー、4層セキュリティモデル。設計の思想と実装の詳細を紹介します。
arcade：ブログにブラウザ用アーケードエミュレータを設置しました
ブログの /arcade/ にブラウザで動くアーケードエミュレータを設置しました。MAME や数十種類のコンソールに対応。ご自身のローカルゲームファイルをドラッグするだけで遊べ、すべてブラウザ内で完結、アップロードなし。
PDLC：AI による開発を「ソフトな慣習」から「ハードな契約」へ
AI が「機能を作りました」と言うが PRD はチャットの中だけ。テストは「あとで追加」。セッションをまたぐと誰もどの機能がどのステージかを覚えていない。PDLC は 31 個の標準化ステージと 5 つの不変条件（Iron Law）でこれを解決する。動機・実装・応用・効果を一気通読。
aitm 初公開：AI をターミナルに組み込む
AI を組み込んだデスクトップ向けターミナルアプリ。macOS と Windows に対応。AI がファイル読み込み、コマンド履歴検索、コマンド実行を行えます。すべての高リスク操作には明示的な確認が必要。
ようこそ、技術ブログへ
個人の技術ブログ最初の記事。何を書いていくか、そしてこのブログで何を得たいかを少し。