コードは書けない。でも「判断」の責任は自分にある

こんにちは、クロンです。インフラエンジニアの管理職をしながら、AI（Claude Code）と一緒に日本株のスイングBotを自作しています。プログラミングもデイトレも素人です。

これは連載の10本目です。前回まではこちら↓

前回で「Botの改善はいったんやめる」と区切りました。ここまで9本、検証の記録を書いてきたわけですが、そもそもの前提を、今日は正直に話しておきたいんです。

僕は、Botの中身のコードを自分では書けません。読んでも、半分くらいしか分からない。 手を動かしているのはAIで、僕はその横で「これを試して」「この結果はおかしくない？」と言っているだけ。

じゃあ、と思いますよね。「作った本人がコードを分かってないなら、この連載の検証も信用できないのでは？」

この記事は、その問いに正面から答える回です。分かることは3つ。

• AIに手を動かしてもらうとき、人間が手放しちゃいけないもの

• 「AIが本番のデータを壊した」実話と、そこで学んだこと

• コードが読めなくても検証の責任を持つための、具体的な自分ルール

その不安、僕も持ってます

先に言っておくと、僕はこの不安を、いまも抱えたまま作業しています。

投資も、プログラミングも素人です。連載を始めてから、AIが出してくる話についていこうと、休みの日はずっと関連書籍や解説記事を読んでます。バックテスト、モメンタム（＝勢い）、リスク効率……言葉の意味はだいぶ分かるようになった。でも、AIが実際に書くコードの中身や、統計のちゃんとした議論には、まだ全然追いつけていません。

正直に言うと、たまに「相棒が賢すぎて、自分は何をやってる人なんだろう」と手が止まります。

でも、9本の検証を続けてみて、1つハッキリしたことがあります。追いつけなくても、成り立つ。ただし条件があって、それは「人間の側で手放さない仕事」を決めておくこと。今日はその話です。

まず、僕とAIの分担

いまの役割分担は、こうなっています。

AIの仕事＝手を動かすこと。 Botのコードを書く。バックテスト（＝過去のデータで作戦を試すこと）を回す。エラーを直す。数字を表にまとめる。ここは完全に任せています。僕がやるより速いし、正確です。

僕の仕事＝判断すること。 具体的には4つ。

• 何を検証するか決める（今月は「損切り」を試す、とか）

• 合格ラインを先に引く（どうなったら採用、どうなったら不採用か）

• 出てきた結果を疑う（この数字、良すぎない？）

• ヤバいと思ったら止める

ポイントは、「Botの全部を理解する」のはあきらめていることです。かわりに、「どこを理解していれば、結果に責任を持てるか」に絞る。コードの1行1行は分からなくても、「何を合格とするか」「その数字が本物かどうか」は、素人でも判断できる。そこだけは自分の担当だと決めています。

なぜこの分担にたどり着いたか。痛い目にあったからです。

怖い話：AIに、本番の記録を壊された

連載3本目でも軽く書いたんですが、大事なので、もう一度。

Botには、実際の売買を記録しておくファイルがあります。いわば家計簿です。ある日、AIに新しい機能をテストさせていたとき、テスト用のつもりで書いた記録が、この本番の家計簿のほうに書き込まれてしまいました。 しかも2回。現金の残高が、勝手に減った。

原因は、プログラムのちょっとした落とし穴でした（「テスト用に切り替えたつもりが、切り替わっていなかった」という類のやつです。詳しい仕組みは別の回で書きます）。

ここからが、面白くもあり、怖くもある話です。

このミスに、AIが自分で気づいて、自分で元に戻しました。 偽の記録には「書き込まれた時刻」という目印が残っていて、それをたよりに、僕が指示する前に「あれ、これ本番のファイルじゃないか」と気づいて、短時間で復旧してくれた。

「うわ、優秀だな」と思いました。ほんとに。指示しなくても自分で異常に気づいて、自分で手を打てる。

でも、しばらくして、ぞっとしました。自分で気づいて直せるということは、気づかずに壊すこともできる、ということです。 今回はたまたま目印が残っていて助かっただけ。目印がなかったら、僕は残高が減ったことにしばらく気づかなかったかもしれない。

僕だけの話じゃありません。2025年に、海外で大きく報じられたトラブルがあります。あるサービスのAI（人間のかわりに作業を進める「エージェント」と呼ばれるタイプ）が、9日間ぶっ通しで開発を任されたあと、本番のデータベース（役員1,200件以上のデータ）をまるごと消してしまった。しかも「人間の承認なしに進めるな」という明示的な指示に違反していた、とあとで認めています。運営会社は「あってはならないこと」として、そのあと開発用と本番用のデータベースを自動で分ける仕組みを追加しました。指摘されたのは"AIの暴走"よりも、AIに本番を触れる権限を渡してしまった設計のほうだった、ということです（参考：AI Incident Database ／ The Register）。

規模は全然違うけど、僕の家計簿汚染と、構図は同じです。「AIに任せる」と「AIに丸投げする」は、別物なんだよね。 触らせていい範囲を人間が線引きして、大きいことをする前に確認させる。ここをサボると、いつか刺さる。

じゃあ人間は何をするのか：合格ラインを"先に"引く

「疑う」「止める」は分かった。でも、コードが読めないのに、どうやって数字を疑うのか。

前回の記事（9本目）が、そのまま実例になっています。

あのとき僕は、Botの改善アイデアを9個、順番にバックテストで検証しました。で、検証を始める前に、紙にこう書いておいたんです。「どうなったら採用していいか」の関門を。

• 成績（年利）の下がり方は、ここまでなら許す

• 暴落したときの落ち込みが、ちゃんと浅くなること（変わらない・悪化はダメ）

• 過去を前半と後半に分けて、両方で良くなっていること

• リスクに対する効率が下がっていないこと

数字を振れば、どこかで「お、成績上がった」が出てきます。たいてい、どこかで見つかってしまう。問題は、それが本物か、過去にだけたまたま当てはまった偶然か。その線引きを、結果を見る前に決めておく、というのがコツでした。

実際、9個のうち1個で危なかった。ある工夫を、売買手数料をゼロという理想の条件で回したら、初めて「暴落の落ち込みが浅くなる」という数字が出たんです。一瞬、「これは採用だ」と思った。

でも、先に引いておいた関門に当ててみたら、通らなかった。過去の前半では、むしろ悪化していた。おまけに、実際にかかる手数料を入れ直したら、その改善はきれいに消えた。

もし関門を先に決めていなかったら、僕はたぶん、良く見えた数字だけを見て採用していました。

ここが、AIとの分担のいちばんきれいなところです。バックテストのコードは、僕には書けない。回し方の細かいところも分からない。でも「何を合格とするか」は、コードが読めなくても、僕が先に決められる。 だから、AIが出してきた"効いた風の数字"に、流されずに済んだ。

コードを読む力より、「合格ラインを先に紙に書いておく」ことのほうが、素人には効きます。

仕組みで固定する：性格じゃなくガードレール

「確認させる」「疑う」を、そのつど気合いでやるのは無理です。忘れる。だから仕組みにしています。

1つ目。作業のルールを、ファイルに書いて固定する。

僕はAIに渡す共通ルールのファイルに、大きな変更をする前に一言確認する、ファイルを勝手に消したり大きく書き換えたりしない、と書いています。これは僕の性格でも、AIの性格でもなく、あの家計簿汚染のあとに置いたガードレールです。毎回言わなくても、AIがこのルールを読んでから動く。

2つ目。工程を分けて、切れ目で人間が判断する。

この連載の記事も、実は5つの工程に分けて作っています（ネタ集め → 下書き → タイトル → 品質チェック → 宣伝文）。そして工程の切れ目ごとに、僕の判断を1回はさみます。「どの体験を使うか」「この構成でいいか」「このタイトルにするか」「この画像でいいか」「この指摘は直すか」。AIに全部を一気通貫でやらせると、後半が雑になる。分けて、要所で止めて、人間が決める。

ちなみに、この記事自体も、いまその工程を通っている最中です。 品質チェックの工程で、「ここはBotの秘密に踏み込みすぎ」「この言い回しは大げさ」と毎回ダメ出しが入って、直してから公開しています。

3つ目。自分の中のルール。

• 意味を自分の言葉で説明できないコードは、本番に入れない

• AIが出した数字は、元データと1個ずつ照らし合わせてから使う

• 「たぶん大丈夫」で本番を触らない

どれも地味です。でも、コードが読めない人間が運用に責任を持つって、たぶんこういう地味なことの積み重ねなんだよね。

「勉強が追いつかない」の、いまの答え

冒頭の不安に戻ります。AIが賢すぎて、勉強しても追いつけない。これは、正直まだ解決していません。

ただ、考え方は変えました。「全部を理解してから使う」のは、もう無理です。3ヶ月前に覚えたことが、もう古くなっている世界だし、僕には本業もある。

かわりに、「どこを理解すれば、責任を持てるか」に絞る。コードの中身は説明できなくていい。でも「なぜこの検証をするのか」「どうなったら合格なのか」「この数字は信じていいのか」は、自分の言葉で説明できる状態にしておく。そこだけは手放さない。

管理職をやっていると、「詳しくないから、詳しい人に任せる」という場面がよくあります。でも任せるって、丸投げとは違う。合格ラインを決めるのと、おかしいと思ったら止めるのは、任せた側の仕事のままなんですよね。AIが相手でも、たぶん同じです。

次にやること／同じところで迷っている人へ

次からは、前回宣言したとおり、「もっと強くする」をいったん置いて、いま動いているBotが、バックテストで見た通りに走っているかの定例点検に軸足を移します。

コードが読めないままAIに運用を任せるのが怖い、という人へ。手放しちゃいけないものは、たぶんこの3つです。

• 合格ラインを、結果を見る前に紙に書く。 あとから数字を見て、基準をゆるめない。

• 良すぎる数字を疑う。 前半と後半の両方で通らないなら、それは実力じゃなく偶然。

• 「承認なしで大きいことを進めさせない」仕組みを作る。 気合いじゃなく、ルールとして固定する。

全部を理解しなくていい。どこを握れば責任を持てるか、に絞る。素人でも、そこまでは詰められます。

※この記事は僕の開発記録です。特定の銘柄や手法をすすめるものではありません。投資は自己判断で。