Archive
これまでに書いたすべての記事。左のタグで絞り込みできます。
build が通っただけでは終わらない — AI 駆動で Done を「運用」した話
AI エージェントに実装を振ると「build 通った！（自前で書いた）UnitTestも通った！！完了！！！」で止まりがちです。レガシー移行の現場で効いたのは、Done を固定値にせず review 2サイクルで動かし続ける運用でした。
- ai-driven-development
- legacy-migration
- workflow
「入力したのに空になる」— WinForms を Web に移すときに踏んだ Tab/blur 依存の罠
WinForms → Blazor の移行中、郵便番号の2分割入力が「入力してください」エラーになる現象を踏みました。原因は、入力値の確定が Tab / blur に依存していたこと。古い GUI パラダイムを Web に持ち込むときに必ず出る罠です。
実装する AI とレビューする AI を分けたら、見落としが激減した話
1つの AI エージェントに実装もレビューもやらせると、どうしても「書いた本人」のバイアスで見落としが残ります。Orchestrator と Sub Agent で役割を分けた運用に切り替えた経緯と、実際に効いたポイントを書きます。
画面の見た目は同じ、でも裏では違うテーブルを消していた話
移行画面の UI は元の VB 版と完璧に一致させたのに、削除ボタンが消すテーブルが違う、Oracle 関数の呼び出しが抜けて名称ではなくコードが表示される、権限制御が API 側で落ちている。「見た目は同じ」「業務は崩れている」バグを連続で踏んだ話です。
精度が出ないのはモデルのせいじゃなかった — Claude Code と Codex を分業させた話
同じプロジェクトで Claude Code と Codex を併用しています。当初は「どちらが強いか」で比べていましたが、答えは「役割を分ける」でした。実装担当と棚卸し・差分検査担当に分けたら、画面移行の漏れが激減した話です。
RateLimit で止まる前提で、開発プロセスを設計する
AI 駆動開発で最初に詰まるのは技術課題ではなく RateLimit です。レビューが止まる日があっても品質を落とさないために、止まったあとの所作をあらかじめ決めておく運用にしました。
未実装ボタンを「動いている風」にしない — 偽の完成を防ぐ UI 戦略
移行途中のフッターボタン群を全部隠すと利用者が混乱します。かといって全部実装すると工数が爆発します。「導線だけ実装して、未対応メッセージで明示する」の中間解にしました。
クエリ駆動の UI 初期化 — 画面間導線で「地味に効く」テクニック
受付区分や処理種別が多い画面では、遷移元から URL クエリで初期状態を渡すだけで操作負荷が大きく下がります。ただし再描画・再遷移時の再適用には注意が必要、という話。
ログは「記録」より「再開ポイント」 — 翌日の自分のために書く
タスクログを「何をやったかの報告書」として書いていると、翌日の再開で必ず迷子になります。「どこから再開できるか」を主軸に書くようにしてから、口頭引き継ぎがほぼ要らなくなりました。
VB ソースを「全部読まない」差分レビュー術
VB の業務ソースを全部読んでから移行を始めると、永遠に終わりません。イベントハンドラと SQL 組み立て箇所に絞って、操作シナリオ単位で比較すると一気に速くなりました。
Build は通るのに業務が壊れる、典型 5 パターン
コンパイル成功とユニットテスト緑だけで「完了」にすると、業務シナリオで普通に壊れます。私が実際に踏んだ 5 つのサイレント失敗パターンを並べておきます。
画面移行の優先順位は「列」ではなく「操作」 — 危ない順に手を入れる
「列が足りません」より「削除ボタンが違うテーブルを消しています」のほうが事故です。見た目を揃える前に、破壊的操作の同等性を先に確認するルールにしました。
「履歴モード」と「最新モード」を持つ画面の二重実装地獄
WinForms 系の業務画面でよくある「全件履歴」と「最新のみ」の切り替え。クエリだけでなく表示列・操作可否まで分岐するので、素直に作ると地獄を見ます。
ContextとLLMの精度を考察
Tokenの上限値が成果物の精度を決定づける要素ではないことを記しました。推論モデルにおけるContextの本質とは「Vectorを決定づける論理性」である。
レガシー移行で効いた「1ファイル 1 目的コミット」戦略
AI に大量の変更を一気にやらせると、レビューが回らずロールバックも難しくなります。コミットを 1 目的に切り刻む運用にしてから、差し戻しコストが目に見えて下がりました。
WinForms の可視 / 活性制御を Blazor で再現するコツ
WinForms の `Visible` / `Enabled` を素朴に Blazor の `@if` / `disabled` に置き換えると、条件式が画面中に散らばって保守不能になります。「計算プロパティに寄せる」だけで世界が変わりました。
「未決」をプロジェクトの進捗として残す — 不明仕様との付き合い方
仕様が曖昧な領域を無理に実装すると、確実に事故ります。「未決のまま、未決と書いて先に進む」運用にしてから、戻り工数がかなり減りました。
レガシー SQL 由来の日本語テーブル名と、どう向き合うか
「漢字混じりのマスタ_明細」みたいな日本語テーブル名と日本語列名は、レガシー業務系の世界では普通にあります。AI に書かせるとここで誤字や同音異義の事故が出やすいので、扱い方をルール化しました。
既存 warning を抱えたまま進む時の安全運転
build warning ゼロは理想ですが、移行フェーズだと現実的じゃないことが多いです。「新規 warning を増やさない」ルールに切り替えてから、進捗と品質のバランスが取れました。
「修正したつもり」を防ぐ、再現シナリオ駆動の修正フロー
コード単位で「直したつもり」になっても、再現シナリオを通すと普通に再現します。修正の検証はコード単位ではなくシナリオ単位、というルールにしてから戻りが減りました。
SubAgent が落ちた日のための、止まらない代替運用
レビュー用の SubAgent が RateLimit で使えなくなる日があります。「止まらない」ことより「止まったときに何をするか」を事前に決めておくほうが、結局は品質を保ちました。
Blazor から DB を直接叩かない、というだけで品質が安定した話
急いでいる移行プロジェクトほど「Blazor のコンポーネントから直接 DB を見ればいいじゃん」という誘惑に駆られます。が、API 境界をきっちり引いておくほうが、結局は速かった。
画面間遷移の暫定実装を「借金化」させない方法
未移行画面への暫定遷移は、放っておくと「動いているように見える」まま技術的負債になります。差し替え予定を契約として明文化することで、借金の利子が雪だるまになるのを防げました。
Evidence 3点運用 — 仕様の暗黙知を実装前に表に出す
「源泉」「意図」「対象」の 3 つを実装前に明示する運用。書くのは 30 秒ですが、これがあるかないかで方針ブレが激減しました。
画面レビューで使える「危険信号チェック」
見た目を揃えるだけのレビューでは、業務破壊系のバグは見つかりません。「危険信号」を先にスキャンする観点リストを Reviewer の固定観点として持つようにしました。
はじめに — このブログについて
AI駆動開発・Vibe Coding・レガシーマイグレーションについて、現場での試行錯誤を書いていきます。
「画面は動く」が一番危ない — 操作権限を UI / API の二重で守る
UI 側でボタンを隠しただけで安心していると、API を直接叩かれた瞬間に終わります。レガシー移行で踏みやすい権限制御の落とし穴と、二重防御をルール化した話です。
既存コードを壊さないための「差分最小主義」
AI に「いい感じに直して」と頼むと、必要のない範囲まで触ってきます。挙動に直結する最小差分を積み重ねる運用にしてから、デグレが目に見えて減りました。
ドキュメント駆動で手戻りを減らす — 実装と同時にmapping/logを更新する
実装後にmappingを更新する運用だと、判断理由や残差分がこぼれます。実装と同じセッションで書くようにしたら、翌日の再開とレビュー判断がかなり速くなりました。
WinForms のイベントを Blazor へ写経しないで「翻訳」する
`btn_Clear_Click` のような WinForms イベントをそのまま Blazor のメソッドに書き写すと、責務分割もタイミングもズレて事故ります。操作シナリオ単位で対応づけ直すと、移行品質がだいぶ安定しました。
「仕様どおり」より「運用どおり」を優先する瞬間
古い業務システムは、仕様書よりも実装そのものが正解として運用されている世界です。文書に書いてある挙動と、現場で使われている挙動が違うとき、どちらを取るかという話。
選択したタグの記事はまだありません。