コードが書けなかった私が、Claude CodeとCodexで自社システムを直すまで

今日は、いつもの「新しい機能の解説」を少し離れて、私自身の話を書きます。

私はエンジニアではありません。自分の手でコードを書いて実装することはできません。けれど、いま私は自社で動いているシステムを自分の手で改修しています。新しい機能の追加もしますし、不具合の修正もします。バグレポートを読んで、原因を特定して、直して、テストする。そのすべてを自分の判断で動かしています。

理由はシンプルで、Claude CodeとCodexがコードを書く部分を補完してくれるようになったからです。

これまでなら、こうした作業はすべて外部のエンジニアに発注していました。いまでは、相当数の改修を自分で完結できます。結果として、外部発注のコストが減り、社外には頼みにくかったスピード感のある改修ができるようになり、新しい受注の幅も広がりました。

この記事では、なぜそんなことが起きるのか、そして、これは私一人の話ではなく、AIというものの効き方の根本に関わる話だ、ということを書きます。

コードが書けない私が、なぜ自社システムを直せているのか

私自身はエンジニア経験がありません。代わりに、PM(プロジェクトマネージャー)的な仕事はずっとしてきました。要件を整理する、仕様の優先順位をつける、エンジニアと議論しながら判断する。十年以上それを続けていれば、システム開発の全体像、よく出てくる用語、何にどれくらい時間がかかるかの肌感は、それなりに身につきます。

ただ、最後の「コードを書く」というピースだけは、自分では埋められなかった。これがあるせいで、システムに手を入れたいときは必ず誰かに依頼する必要があり、依頼すれば当然コストがかかり、納期もかかり、優先順位もこちらの思い通りにはいきません。

ここに Claude Code と Codex が入ってきて、状況がはっきり変わりました。私が日本語で「この画面のこの動作をこう直したい」と書くと、AIが該当ファイルを読み、変更案を出し、テストまで通します。私はその変更内容を読み、意図どおりかを判断し、必要なら修正を指示する。コードを書く工程だけがAIに移って、それ以外の判断は私が握ったまま動かせるようになりました。

結果として、相当数の改修が社内で完結するようになり、これまで外部に出していたコストが減りました。同時に、これまでは「人手の都合で見送っていた」修正にも手が届くようになり、ちょっとした改善が積み重なってサービスの体験が良くなっています。いまでは既存システムの修正にとどまらず、一から新しいシステムを構築することもできるようになりました。この自分で動かせる範囲の拡張が、新しい案件の受注にもつながり始めています。

これは「うまく自動化できた」という話とは、少し性格が違います。

AIの2つの効き方 自動化と「補完」は別の話

AI活用の議論は、いま「自動化」に大きく偏っています。請求書処理、議事録の文字起こし、メールの返信案、データ集計。どれも、人間が既にやっていた作業を、AIが速く・安く・安定して回せるようにする話です。これはこれで効果があります。

ただ、私の実体験は、もう一つ別の効き方を示しています。それは補完です。これまで自分にはできなかった作業を、AIが穴埋めしてくれることで、自分が新しい仕事をできるようになる、という効き方です。

自動化と補完は、表面的には似ていますが、性質がまったく違います。

効き方	何が起きるか	効果
自動化	自分が既にできていた作業を、AIが代わりにこなす	時間とコストの削減
補完	自分にはできなかった作業を、AIが穴埋めし、自分が新しい仕事に踏み出せる	自分の引き出しが増える

業界では、自然言語でコードを書く流れを「バイブコーディング」と呼ぶことがあります(Andrej Karpathy 氏が2025年2月にX上で言及したのが起点で、Collins Dictionaryの2025年度ワードにも選ばれました)。私のやっていることは厳密には「コードを忘れて雰囲気で書く」までは行かず、もう少し慎重に判断は手元に残しています。それでも、コードを書ける人の幅が広がっているという業界全体の流れの中に、自分も入っている実感があります。

そして、自動化が「同じことを速く回すための効率化」だとすると、補完は「これまでできなかった仕事ができるようになる、人の能力そのものの拡張」です。後者のほうが、利益のレバレッジは大きいことが多いです。

「補完」が利益を作る瞬間 内製化・新規受注・撤退回避

補完が利益に直結する場面を、3つに整理します。

1つ目は内製化です。これまで外部に発注していた仕事を、自分たちで完結できるようになる。発注コストがそのまま消え、改修のリードタイムも短くなり、コミュニケーションの摩擦も減ります。私の場合、自社システムの改修と、新しいシステムの一からの構築がここに該当します。

2つ目は新規受注です。これまで「うちでは対応できない」と断っていた仕事を、受けられるようになる。AIによる補完で、自社の対応範囲が広がるという形です。私たちの場合、開発のスピード感を活かして取れる案件の幅が広がりました。

3つ目は撤退回避です。人材確保が難しくて事業を縮小・撤退しようとしていた領域を、AIの補完によって細々とでも続けられるようになる。IPAのデジタル人材の動向調査を見ても、DX推進人材の「量」が大幅に不足している企業は、2022年度調査で49.6%にのぼります。人材が足りないから事業をたたむ、という判断が現実的になっている企業は少なくないはずです。AIによる補完は、その手前で踏みとどまるための選択肢になり得ます。

この3つは、いずれも「自動化」では出てこない種類の効果です。自動化は既存業務を圧縮するだけですが、補完は新しい収益や継続できる事業を作る方向に効きます。

補完されるのはコードだけではない

ここまでコードの話をしてきましたが、補完の対象はコードだけに限りません。少なくとも、次のような領域では同じ構造のことが起きやすいと感じます。

• 英語: 海外メーカーの技術資料、英文契約書、海外ベンダーとのメール。中身は理解できる(あるいは理解すべき立場にある)けれど、英文を自分で書ききるのは時間がかかる人。AIが下訳と要約をすれば、自分の判断で英語のやりとりを動かせるようになります
• デザイン: ラフ画はある、伝えたい雰囲気もある、けれど自分で清書はできない人。画像生成AIや生成系のデザインツールが、最終仕上げの部分を埋めます
• データ分析: 何を見るべきかは分かっている、けれど SQL や Excel関数 を自分で組むのは苦手な人。AIに依頼すれば、見たい切り口で集計してくれます
• 文書設計: 企画書・提案書の中身はある、けれど構成とトーンを整えるのが苦手な人。AIが下書きと構成案を提示します

共通しているのは、「業務理解はあるが、形にする最後のピースが足りない」職種です。コードが書けない私と同じ構図が、英語が書けないPM、デザインができない企画担当、SQLが書けない営業企画、構成が組めない事業責任者にも当てはまります。

逆に、業務理解そのものが薄い人がAIに丸投げしても、補完は起きません。理解の上にAIが乗って初めて、補完は補完として効きます。

補完を起こすための、3つの前提

補完が利益に変わる現場を私自身が動かしてみて、これは外せないと感じる前提が3つあります。

1. 「補完されたい部分」の手前まで、ある程度の理解があること

AIに何かを任せるとき、結果を読み解けるだけの理解は最低限必要です。私の場合、コードは書けませんが、「この変更が他にどんな影響を与えそうか」「この修正で本当に問題が直っているか」を判断するためのシステム全体の理解はあります。これがゼロだと、AIが出した結果が正しいかどうかすら判定できず、補完ではなく単なるブラックボックスへの丸投げになります。

2. 試行錯誤を続けられる時間と権限があること

最初の数日から数週間は、失敗の連続です。プロンプトの書き方、AIへの仕事の渡し方、結果のレビューの仕方、それぞれを自分の業務に合わせて調整する時間が要ります。経営者なら自分の裁量でこの時間を取れますが、現場の社員に同じことを期待するなら、その時間と権限を会社として認める必要があります。

3. 最後は自分が判断する、という覚悟があること

AIに任せきりにしないこと。出てきた結果を読み、意図どおりかを判断し、責任は自分が持つ。この覚悟がない人は、補完の話に踏み出さないほうが安全です。AIが書いたコードがそのまま本番に出ていって不具合が起きたとき、「AIがそう言ったから」では済まないからです。

この3つが揃っていれば、補完は確実に起きます。逆に、どれかが欠けていれば、補完は単なる自動化のレベルで止まります。

AIにコードを書かせるときに、最低限守っていること

ここまで前向きな話を続けてきましたが、AIに自社システムを直させるなら、最低限のガードレールは欠かせません。本番環境を直接触らせるとか、認証情報をそのまま渡すとか、雑な使い方をすると一発で事故ります。私が自社システムを動かすときに、絶対に守っているルールを6つだけ挙げておきます。

• 本番環境を直接触らない(必ずローカルか検証用の環境で動かす)
• Gitで変更差分を必ず残す(何を変えたか後から追えるようにする)
• 変更前にバックアップを取る(データを触る変更は特に)
• テスト環境で確認してから反映する(目で見て、動かしてから本番へ)
• 認証情報や秘密鍵をAIに渡さない(プロンプトに貼らない、リポジトリに入れない)
• 分からない変更はそのまま採用しない(意図を理解できないコードを通さない)

どれも特別な話ではなく、ふつうのソフトウェア開発で当たり前に守られているルールです。AIが間に入っても、ここを変える必要はありません。むしろ、AIが「ぱっと見もっともらしく動くコード」を返すことが増える分、ここを意識的に守るほうが事故率は下がります。

社内で誰かに同じことを始めてもらうなら、まず最初にこのガードレールを共有してください。話はそこからです。

さいごに 「自分には無理」と諦めていた領域を、もう一度見直す

AI活用の話題は、どうしても「業務を自動化して時間を削る」方向に偏りがちです。それも大事なのですが、私自身の実感として、本当に効いてくるのは「これまで自分には無理だと諦めていた領域」の補完のほうです。

数年前なら、私がコードを書いて自社システムを直すなんて、現実的な選択肢ではありませんでした。いまは違います。同じことが、これを読んでいる経営者・現場リーダーの「自分にはできない」と諦めていた領域にも、起きる可能性があります。

英語が書けないから断っていた仕事、デザインが組めないから外注に頼っていた案件、データ分析ができないから判断を先送りにしていた意思決定。それぞれの後ろにある「もし自分でできていたら…」の領域に、いま、AIが補完を持ち込みます。

自動化の話は他社もしています。補完の話は、自社の中でしか見つけられません。最初の一歩は、自分の引き出しを棚卸しして、「自分には無理だと思って諦めていたこと」を一つ書き出すところからです。