AIにコードを書かせるとき人が決めること

AIにコードを書かせると、動くものが速く出てきます。 そして、動いたことは正しいことの証明になりません。 権限の設定、秘密情報の置き場所、戻し方、引き継ぐ人が読める説明——これらは画面を触る確認では表に出てきません。 この章は、コードが読めない人が、何を決め、何を聞けば事故を止められるかの章です。

この章で分かること

• 人が決めなければならない4つ（作るもの・触ってよい範囲・試す場所・戻し方）
• コードが読めなくても確認できる5つの観点と、その聞き方
• 速く作れることで何が壊れるか（作った本数ではなく、持ち切れる本数で考える）

動作確認で分かること、分からないこと

「動きました」を受け取ったとき、確認できているのはこの表の左だけです。

動作確認で分かること	動作確認では分からないこと
想定した操作で、想定した結果が出る	想定していない入力を入れたときにどうなるか
画面が表示される	誰が見られる設定になっているか（権限）
データが保存される	保存先がどこか。外部に送られていないか
処理が終わる	途中で失敗したときに、どこまで進んだ状態で止まるか
今日動く	元にしている外部サービスが変わったときに動き続けるか

右の列は、触っても出てきません。 だから、動作確認とは別に「聞いて確かめる」手順が要ります。 この章の点検リストは、そのための質問リストでもあります。技術が分からなくても、質問はできます。

人が決める4つ

AIに任せられないのは、能力の問題ではなく、決める材料が社内にしかないためです。

#	人が決めること	決めないとどうなるか
1	何を作るか（1枚の仕様）	それらしいものが出てきて、要る機能が抜け、要らない機能が付く
2	触ってよい範囲	関係のないファイルや設定まで書き換わる
3	どこで試すか	本番のデータで試すことになる
4	戻し方	壊れたときに、止めることも戻すこともできない

1の「1枚の仕様」は、設計書である必要はありません。誰が、どの画面で、何をしたら、何が起きてほしいかが書いてあれば足ります。 実務で最もよく起きる失敗は、この1枚が無いまま作り始め、出てきたものを見ながら要件を思い出す形です。この進め方だと、何が完成なのかが最後まで決まりません。

コードが読めなくても確認できる5つ

出来上がったときに、この5つを聞いてください。答えが返ってこない項目が、危ない場所です。

#	観点	聞き方	危ない答え
1	秘密情報	「パスワードや鍵は、どのファイルに書いてありますか」	「コードの中に書いてあります」
2	権限	「これを見られるのは誰ですか。社外の人が開けますか」	「URLを知っている人だけです」（＝知られたら開ける）
3	外部への通信	「どこに通信していますか。一覧はありますか」	「特に意識していません」
4	戻し方	「壊れたとき、誰が、どうやって元に戻しますか」	「作り直します」
5	引き継ぎ	「別の人がこれを直すとき、何を読めば分かりますか」	「私に聞いてください」

1が最重要です。鍵やパスワードがコードの中に直接書かれていると、そのコードを共有した時点で鍵も一緒に渡ります。 設定ファイルに分けておけば、コードだけを渡せます。 2は、社内向けの道具ほど見落とされます。「社内の人しか知らないURL」は、権限ではありません。 5は、作った本人が辞める・異動するまで問題になりません。だから後回しになり、問題になったときには手遅れです（9章）。

本番のデータで試さない

一番多い事故がここです。「ちょっと試すだけ」で本番のデータを触ると、取り消せません。

用意するもの	中身
試す場所	本番と別の環境。無料枠や試用環境で足りることが多い
試すデータ	本番のコピー、または作ったデータ。個人情報は入れない（3章）
本番に出す条件	動作確認・戻し方・責任者の3つが揃ってから

当社は kintone の開発・検証を開発者ライセンスの環境で行い、クライアントの環境で作ったものをそのまま製品にしません。 事故を防ぐためと、成果物の権利を曖昧にしないためです。 本番と別の環境が用意できない場合は、作る対象を変えてください。 環境が無いまま進めるより、別の業務から手を付けるほうが早く進みます。

速く作れることで壊れるもの

これがこの章の本題です。作る速さが上がると、作る量が増えます。 増えて壊れるのは、作る側ではなく、持ち続ける側です。

増えるもの	起きること
似た道具が何本もできる	どれが現行か分からなくなる。直すときに全部直す羽目になる
誰も使っていない道具が残る	動き続け、壊れたときだけ気づく
作った本人しか触れない道具が増える	その人の作業量が増える。異動できなくなる
外部サービスにつないだ道具が増える	つなぎ先が変わるたびに、どれが影響を受けるか分からない

当社の決めごと：作った道具は一覧にし、使われていないものは止める。 理由は、動いているものの本数と、責任を持って直せる本数が離れるほど、事故の発生源が見えなくなるためです。 「何本作ったか」は成果ではありません。何本、責任を持って直せる状態で持っているかが成果です。

外注先がAIを使っている場合に確認すること

外注の見積が急に安くなった、納期が急に短くなった——という場面が増えています。良し悪しの前に、確認する項目は決まっています。

確認すること	聞き方
成果物の権利	「納品物の著作権と、改変してよい範囲は契約のどこに書いてありますか」
秘密保持	「当社から渡した資料を、外部のサービスに入力しますか。入れる場合、その扱いは確認済みですか」
引き継ぎ物	「解約したとき、何を受け取れますか（コード・設定・手順書）」
動作の保証	「不具合が出たときの対応範囲と期間は、どこに書いてありますか」
誰が直すのか	「作った人が辞めたとき、誰が直しますか」

AIを使っているかどうかを問うのではなく、この5つが契約書に書いてあるかを見てください。 どの作り方であっても、必要な項目は同じです。 判断に迷う見積は、第三者に見てもらう手もあります（見積のセカンドオピニオン）。

当社の作り方（実物）

当社は kintone プラグイン23本とこのサイトを、AIを使って作っています。人が必ず見る場所は固定しています。

工程	任せている範囲	人が必ず見る場所
仕様	案を出させる	何を作るかの決定（1章の段階4）
実装	任せる	触る範囲の指定、秘密情報の置き場所
テスト	テストの作成まで任せる	テストが通ったことと、実際に触っての確認
公開	準備まで	公開してよいかの判断。戻し方の確認

導入の全体像や、開発にAIを使う道具そのものの説明は記事に譲ります（Claude Codeとは？中小企業のための完全入門ガイド／MCP連携とは？AIと外部ツールを繋ぐ新しい方法）。

開発でAIを使わないほうがよい場合

状況	判断
本番と別の環境が用意できない	作らない。環境を用意するのが先
直せる人が社内に1人もおらず、外にも頼んでいない	作らない。動き続けるものを、誰も止められない状態になる
既存のサービスの標準機能で足りる	作らない。作ったものは保守が発生し続ける
お金や個人情報が動く処理で、戻し方が作れない	作らない（1章の問い1）
1回きりの作業	道具にしない。その場で終わらせる

2行目が現実的に一番重いです。作れることと、持てることは別です。 持てないものを作ると、半年後に「触ると壊れそうだから放置している」状態になります。

よくある間違いを5つ

「動いたので本番に出した」 ——動作確認で分かるのは、想定した操作の範囲だけです。権限・秘密情報・戻し方は出てきません。直し方：5つの観点（秘密情報・権限・通信・戻し方・引き継ぎ）を聞いてから出す。

「ちょっと確かめるだけなので、本番のデータで試した」 ——取り消せない操作が混ざると終わりです。直し方：別の環境を先に用意する。用意できないなら、その業務は後回しにする。

「動いているので、説明書は後で書くことにした」 ——後で書かれることはありません。書くのは、作った直後の、作った本人だけです。直し方：手順書とREADMEを成果物に含める。無いものは未完成として扱う。

「速く作れるので、思い付いた道具を次々に作った」 ——半年後、どれが現行か分からない道具が並びます。直し方：作った道具を一覧にする。使われていないものは止める。

「外注先にAIの使用を禁止した」 ——確認すべきは使用の有無ではなく、権利・秘密保持・引き継ぎ物です。禁止しても、それらが契約に書いていなければ守られません。直し方：契約の5項目を確認する。

この章の出口

この章を終えたとき、手元に残っているべきものは3つです。

1. 1枚の仕様（誰が・どこで・何をしたら・何が起きるか）
2. 5つの観点の答え（秘密情報・権限・通信・戻し方・引き継ぎ）
3. 戻し方を一度試した記録と、責任者の氏名

ここまでで「任せる」の4章が終わりました。文章・データ・開発の、人が見る場所が決まったはずです。 ただし、ここまで全部を1人でやっていると、その人が抜けた日に全部止まります。 次はそこを扱います。

次の章へ：9章 AI活用を社内に残す｜属人化させない