tauridev｜AI・外注アプリの診断・Windows開発

AIや外注で作ったアプリの不具合を診断・修正します。Rust・TauriのローカルWindowsアプリ開発も。AIの回答だけで判断せず、実際に再現して確かめる。ご相談はテキストで完結（通話なし）。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

この「動くけど不安」の診断は、ココナラでやっています。症状の再現→原因→影響範囲を2〜4ページのレポートにして納品します（原因を特定できなかった場合も確認した範囲を必ず納品・表示価格が総額です）。まず相談だけでもどうぞ→ https://t.co/PBmRXx2ofa

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

全文はこちら(ココナラブログ・コピペで使える契約前/納品前の確認文つき):
https://t.co/2M1SgtLhmD

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

「完成しました。テスト済みです」——外注やAIで作ったアプリの納品で、この言葉だけを頼りに受け取っていませんか。

コードが読めなくても確認できるものを、発注者向けに5つにまとめました。

・何を確認し、何が「未確認」かが分かる一覧(成功件数だけでは分からない)
・実利用に近いダミーデータでの画面録画
・自分の環境で再現するための手順
・(データ更新や決済があるなら)わざと失敗させたときの動作
・(同上)問題が起きたとき戻す方法

開発側にも逆向きに使えます。これを聞かれる前に出せば、「何をもって完成とするか」の合意が一往復で終わる。

大事なのは開発者を疑うことではなく、双方で完成の条件を揃えることでした。全文は↓のリプに。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

AIの要約に「このリポジトリにexe配布の記載はない」と言われても、それは"不在の証明"にはなりません。
偽陰性を2回踏んで決めた個人ルール。
・存在候補を探すときは要約を使う
・実際に採用するときは原文を見る
・「存在しない」と判断するときは、対象範囲を決めて原文検索までやる
AIの回答を検証するコストは、「ある」と「ない」で非対称です。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

Codexのsandboxが「CreateProcessAsUserW failed: 5」で、すべて失敗するようになりました。
一時的にsandboxを外すと動くため、最初はsandbox自体の故障だと判断しかけました。しかし、私の環境での原因はPowerShellでした。
WindowsApps配下のMSIX版PowerShellを、sandboxの低権限ユーザーから起動できていなかった。MSI版のPowerShell 7を明示して入れ直すと、隔離を維持したまま解消しました。
最初に見えたエラーで診断を固定すると、真因に届く前に「安全機構を外す回避策」の方が恒久化する。怖かったのはエラーそのものより、回避策が正常運用になりかけたことでした。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@koneko_seijin_m まさにそこが本丸だと思います。0→1で動かすのはAIで一気にいけても、「バグが出た時に直せる状態か」は別問題で…。最初に作った人が構造を把握してないと、修正のたびに別の所が壊れるループに入りがちなんですよね。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@YossyFPS 「ミラクルで動いていた」ところが直すと壊れる、めちゃくちゃあるあるです…。あれ実は最初から論理は間違っていて“たまたま通ってただけ”のが、正式実装にした瞬間に炙り出されるんですよね。壊れて見えるようになった分むしろ健全化してるという。直してて一番ヤバかった箇所ってどこでした？

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@miiitaka 「動くようにして」って、一番ざっくりして一番地雷ですよね…。AI生成コードを120本ほど検証したとき、派手に落ちるより「動いてるように見えて一部だけ黙って壊れてる」型が厄介で、そこの切り分けにいつも時間が溶けました。まなびとさんのところにも、そういう相談増えてますか？

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

永遠のリックロール、平和で笑いました。ただ「検証で外部URLを勝手に選ぶ」のは地味に怖くて、検証用のURLは自分で固定して渡すようにしています。意図しない外部依存が入ると再現もできなくなるので…。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

一気通貫の基盤づくり、いいですね。リトライ設計で個人的に一番効いたのは「何をもって失敗とするか」を実行結果の実数で持つことでした。exit 0やテスト緑をトリガーにすると、実は0件しか走っていないのに成功扱いでリトライが素通りする型があって…。失敗検知が甘いとリトライが空回りするんですよね。先日の二段階体制の話とも地続きで面白いです。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

「触れる範囲を狭めとけ」、受託で毎日運用してる人の実感だと重みが違いますね。自分も削除・上書き系は「実行前に対象の一覧を出させて人間が承認」のワンクッションを挟むだけで事故がだいぶ減りました。AIに任せる工程と人間が見る工程の切り分け、まさに同じところを検証しています。線引きはどのあたりで引いていますか？

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

「AI自身に見直させる」が意外と効かない、というのが実測での気づきです。160問で試したところ、自分の出力を見直させても単に再実行するのと精度が変わりませんでした。なので担保はAIの外に置いています。出力に出てくる数値を抜き出して元の試算表と機械的に突合する、季節変動のような業種知識はAIに期待せず人間側の確認リストに持つ、の二段です。読み違えた季節変動のパターン、次回用のルールとして貯めていたりしますか？

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

「作れること」の価値低下、検証する側としても同じ実感です。AI生成コードを120本動かして検証したことがあるのですが、派手に壊れるものより「動いているように見えて黙って間違う」ものが一番厄介でした。なので任せる範囲の設計は「間違ったとき、誰が（何が）気づけるか」で線を引くようにしています。現場で使われ続ける運用の鍵、岡田さんは何が一番大きいと感じますか？

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@yorrielle Git保存のルール化にxcopy/rsyncまで仕込んであって、消えたのが作業途中のファイルだけなら、備えはちゃんと機能していますね。「余裕のつもりが油断」はAI協業の教訓として名言だと思います。委任の線引きは事故のたびに一段賢くなるので、安い授業料だったということで…！

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@keita_nibo こちらこそです。ひとつだけ補足すると、監査側の再実行は「通ったか」だけでなく「テストが何件実行されたか」の実数まで見るようにしています。実は1件も走っていないのに緑、という型が一番気づきにくいので…。read-onlyの線引き、応援しています。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@keijiro_im リポジトリなしでの「いきなり修正」は戻れないので怖いですよね。使い捨ての検証フォルダでも、最初に git init して1コミットだけしておくと、コストほぼゼロで全部戻せる保険になるのでおすすめです。プランモードの再現条件、もし絞れたらぜひ共有してください。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@shion_takk そうなんです、対話の滑らかさを取るか、後から一式追える単純さを取るかの選択だと思っています。MCPで痕跡側に寄せようとすると結局ログ整備が要るので、割り切りが楽でした。建築設計×AIの視点、面白いので発信楽しみにしています。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@n416 「分からないと感じた時点で止まってmd書き直し」、それが正解だと思います。うちはAIに書かせる中間mdに「人間が読んで分かるか」を完了条件として入れるようにしました。理解できない要約を通すと、次の工程の事故が予約されるんですよね。

[tauridev｜AI・外注アプリの診断・Windows開発 @tauridev]

@run0d4v1ia 分かります。自分は「全部読む」のをやめて、①まず動かして表示と実件数を見る ②差分のうち状態を持つ箇所だけ読む、の順にしたら止まらなくなりました。AIのコードは読ませる量で殴ってくるので、読む前に動かすのが効きます。