AIコーディングとは｜3つの型と向き不向きの全体像

「AIコーディング」という言葉を聞いて、多くの方が思い浮かべるのは「AIがコードを書いてくれるので開発が速くなる」という絵だと思います。半分は当たっています。ただ、その絵のままツールを入れた会社は、たいてい3か月目に止まります。

止まる理由ははっきりしています。AIコーディングで本当に変わったのは「書く速さ」だけではないからです。書く時間が短くなったぶん、読む・直す・引き継ぐという仕事の比重が上がります。ここを見落としたまま「速くなるはず」と期待すると、現場では「かえって忙しくなった」という感想が返ってきます。

この記事は、AIコーディングの全体像を俯瞰するための入口です。個別ツールのボタンの押し方は書きません。代わりに、ツールには3つの型があること、それぞれ誰に向くのか、何が向き不向きか、非エンジニアがどこまで触ってよいのか、そして速く書けるようになると何の仕事が増えるのかを、正直に整理します。

数字はIPA（独立行政法人情報処理推進機構）や総務省の公表資料、機能とプランは各社の2026年8月時点の公式ページで確認したものだけを使います。個別の道具の手順は、それぞれの詳細記事へリンクで送ります。

結論｜変わったのは速さだけでない

先に結論を書きます。AIコーディングを導入して起きるのは、開発という仕事の総量が減ることではなく、仕事の中身が入れ替わることです。

増えるのは読む・直す・引き継ぐ

コードを打ち込む時間は、たしかに大きく減ります。一方で次の3つは増えます。

1. 読む時間。自分が書いていないコードを、正しいかどうか判断するために読む
2. 直す時間。動くけれど意図と違うものを、意図に合わせて修正する
3. 引き継ぐ時間。なぜそう作ったのかを、あとから他人が分かる形で残す

この3つは、AIが肩代わりしにくい領域です。AIは「作る」を速くしますが、「決める」「確かめる」「残す」は速くしません。だからAIコーディングの成否は、作る速さではなく、増えた確認作業をさばく仕組みを作れるかで決まります。

この記事の読み方と詳細記事

本記事は全体像だけを扱います。具体的な操作や導入手順は、次の記事に分けてあります。エディタで書く道具の手順はCursorの使い方、端末で任せる道具で業務に載せるものを作る工程はClaude Codeで開発する、小さな道具を試しに作る話はAIでアプリを作るです。

「どこまでAIに任せてよいか」という概念の整理はバイブコーディングとは、生成物を確認する側の話はAIコードレビューにまとめています。

AIコーディングとは何か

AIコーディングとは、生成AIにコードの作成・修正・説明を任せながら開発を進めるやり方の総称です。特定の製品名ではなく、進め方の呼び名だという点が最初のつまずきになりやすいところです。

3つの段階に分けて理解する

「AIにコードを書かせる」と一口に言っても、任せる度合いには段階があります。この段階を混ぜて話すと議論が噛み合いません。

右へ行くほど速くなりますが、右へ行くほど「確認する能力」が問われます。補完なら数行を目で追えば済みます。丸ごと任せると、返ってくる差分が数百行になることも珍しくありません。ここで読めなくなると、AIコーディングは「よく分からないものが増える装置」に変わります。

補完から任せるへの変化

2022年から2023年頃のAIコーディングは、ほぼ補完の話でした。今は3段階目、つまりエージェント型と呼ばれる「目的を伝えると自分で調べて複数ファイルを直す」形が中心になっています。

実際、Anthropicの公式ドキュメントはClaude Codeを「コードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携するエージェント型のコーディングツール」と定義し、ターミナル・IDE・デスクトップアプリ・ブラウザで利用できると説明しています。（出典：Claude Code公式ドキュメント「Overview」。2026年8月時点）

この変化が重要なのは、「エディタを開く人だけの話ではなくなった」という点です。ファイルを読んで書き出す作業なら、コードでなくても扱える道具になったため、開発以外の業務にも入り口ができました。

バイブコーディングとの関係

近い言葉に「バイブコーディング」があります。こちらはコードをほとんど読まずに、対話だけで作り上げる進め方を指す言葉として使われます。AIコーディングという大きな枠の中の、任せ方が最も強い一形態だと考えてください。

両者を区別すべき理由は、適用してよい範囲が違うからです。読まずに作ってよいのは、壊れても業務が止まらないものに限られます。この線引きはバイブコーディングとはで詳しく扱っています。

何が変わったのかの正体

「AIコーディングで開発が変わった」と言うとき、実際には何が変わったのか。ここを具体的に押さえると、期待値の設定を間違えなくなります。

書く時間は仕事の一部でしかない

そもそも、開発という仕事のうち「文字を打ち込んでいる時間」は一部です。IPAは、AIを用いたソフトウェア開発の活用場面として要件定義、議事録管理、コード生成・ペアプログラミング、レビュー、テスト・テストデータ作成を挙げています。（出典：IPA「AIを用いたソフトウェア開発」）

同機構の「2024年度ソフトウェア動向調査」でも、AI導入状況は要求・要件定義／システム設計／製造／テスト／運用という工程ごとに分けて調べられています。（出典：IPA「2024年度ソフトウェア動向調査（企業向け）単純集計グラフ」）

つまり「製造」だけが速くなっても、前後の工程が同じなら全体はそこまで速くなりません。要件が固まっていない状態でコードだけ速く出ると、むしろ作り直しが増えます。要件の詰め方は要件定義の進め方にまとめています。

読む時間が増える理由

AIが生成したコードは、人が書いたコードより読みにくいわけではありません。問題は量と速度です。1時間で人が書ける量と、1時間でAIが出せる量には差があります。同じ時間で流れてくる差分の量が増えれば、読む側の負担はそのぶん増えます。

さらに厄介なのは、AIの出力は文法的に正しく、それらしく見える点です。明らかに壊れているコードなら実行した瞬間に分かります。危ないのは、動くけれど業務要件を満たしていないコードです。金額の丸め方、日付の境界、権限の判定は、静かに間違います。

直す・引き継ぐの比重

3つ目が引き継ぎです。人が書いたコードには、書いた本人という「聞ける相手」がいます。AIに任せて作ったものは、指示を出した人が経緯を覚えていなければ、誰にも聞けません。

当社が中小企業の相談を受けていて最も多いのが、この形の詰まりです。「3か月前に作ったツールが動かなくなったが、どういう考えで作ったか思い出せない」。AIコーディングを導入するなら、作る速さと同じだけ、記録の仕組みに手を入れる必要があります。その具体的な残し方はClaude Codeで開発するで工程として扱っています。

ツールの3つの型

ここからが本題です。AIコーディングのツールは数え切れないほどありますが、役割で分けると3つの型に収まります。製品名を覚える前に、型を覚えてください。

型1 エディタ内で書く

1つ目は、コードエディタの中にAIが組み込まれている型です。代表例はCursorとGitHub Copilotです。入力の続きを予測する補完、選択した範囲だけを書き換える部分修正、エディタ内で複数ファイルを扱うエージェント機能が、同じ画面の中に載っています。

この型の価値は「手を動かしながら使える」ことに尽きます。画面を切り替えず、差分を目で追いながら進められるので、細かい修正の連続に強い型です。逆に、エディタを開かない仕事には使いようがありません。

料金は2026年8月時点で、Cursorが無料のHobby、Pro月20ドル、Pro+月60ドル、Ultra月200ドル、Teams Standard 40ドル／ユーザー／月、Teams Premium 120ドル／ユーザー／月です。（出典：Cursor公式ヘルプ「料金とプラン」。2026年8月時点、税別）

GitHub Copilotは、Free、Pro月10ドル、Pro+月39ドル、Max月100ドル、Business 19ドル／席／月、Enterprise 39ドル／席／月というプラン構成です。（出典：GitHub Docs「Plans for GitHub Copilot」。2026年8月時点、税別）

操作の手順そのものはCursorの使い方で扱っています。

型2 端末で丸ごと任せる

2つ目は、ターミナル（黒い画面）を起点に、目的を伝えて丸ごと任せる型です。代表例はClaude Codeで、公式には「ターミナル、IDE、デスクトップアプリ、ブラウザ」で使えると説明されています。（出典：Claude Code公式ドキュメント「Overview」）

この型の価値は「作業の起点がエディタに縛られない」ことです。複数ファイルにまたがる調査や修正はもちろん、ファイルを読んで書き出す仕事全般に広がります。Excelの集計、報告書の下書き、手順書の更新といった、コードではない作業まで同じ道具で扱えるのが特徴です。

料金は2026年8月時点で、Claudeの個人向けがFree、Pro月20ドル（年払いは月17ドル）、Max月100ドルから、法人向けTeamは標準シートが年払いで月20ドル／席、プレミアムシートが年払いで月100ドル／席です。有料プランにClaude Codeが含まれます。（出典：Claude公式「Plans & Pricing」。2026年8月時点、税別）

この型は権限の扱いが要になります。Claude Codeの公式ドキュメントは既定では厳格な読み取り専用の権限で動作し、ファイル編集やコマンド実行が必要になった時点で明示的な許可を求めると説明し、さらに「Claude Codeはあなたが与えた権限しか持たない。承認する前に、提案されたコードとコマンドの安全性を確認する責任は利用者にある」と明記しています。（出典：Claude Code公式ドキュメント「Security」）

型3 レビューに使う

3つ目は、書かせるのではなく、書かれたものを点検させる型です。プルリクエスト（変更を取り込む前の確認単位）に対して自動でコメントを付ける仕組みが代表例です。

GitHub Copilot code reviewは、コードにフィードバックを返し、可能な場合は数クリックで適用できる修正案を出します。ただし公式ドキュメントはCopilotが残すのは常に「Comment」であり、「Approve」や「Request changes」ではないこと、したがって必須の承認としてカウントされず、マージを止めることもないと明記しています。（出典：GitHub Docs「Using GitHub Copilot code review」）

Cursor側にはBugbotがあり、プルリクエストを確認してバグ・セキュリティ上の問題・コード品質の問題を指摘します。（出典：Cursor公式ドキュメント「Bugbot」）Claude Code側も、GitHub Actionsを使ってコードレビューや課題の仕分けを自動化できると案内されています。（出典：Claude Code公式ドキュメント「Claude Code GitHub Actions」）

この型の位置づけは「人のレビューの置き換え」ではなく「一次拾い」です。公式側が承認権限を持たせていないことが、その設計思想を表しています。考え方の詳細はAIコードレビューにまとめました。

型ごとの比較表

3つの型を並べて比較します。「どれが優れているか」ではなく「自社にどの作業があるか」で読んでください。

（価格の出典：Cursor公式ヘルプ「料金とプラン」／GitHub Docs「Plans for GitHub Copilot」／Claude公式「Plans & Pricing」。いずれも2026年8月時点、税別）

誰がどの型を使うのか

型が分かったら、次は担当者との対応づけです。ここを間違えると、道具のせいではなく配り方のせいで失敗します。

職種別の入口

会社の状況別の選び方

組織単位で見ると、判断は次の一問に集約されます。「エディタを開く仕事が、社内に週何時間あるか」です。

週に10時間以上あるなら、型1を使う人が確実にいます。ほとんどないなら、型1を全社に配っても使われません。この場合の入口は型2です。エディタを前提としない道具のほうが、非開発部門まで届きます。

型3は、人数が2人以上いて、他人の変更を確認する場面がある組織から意味を持ちます。1人で作って1人で使っているうちは、レビュー自動化より先に「自分で確かめる手順」を作るほうが効きます。

主要ツールの現在地

製品の話を、判断に必要な範囲だけ整理します。細かい機能名は数か月で変わるため、覚えるべきは構造のほうです。

料金の考え方と注意点

3社とも、無料枠があり、個人向けの入口が月20ドル前後、上位プランが月60ドルから200ドル、法人プランが1席あたり月19ドルから120ドルという構造になっています。金額の水準はどこも近く、価格で選ぶ意味はほとんどありません。

注意すべきは、月額を払えば無制限に使えるとは限らない点です。多くのサービスが月ごとの利用枠を設けており、使い切ると追加課金か上位プランへの移行を選ぶ形になります。導入初月は上位プランを契約せず、実際にどれだけ使うかを実測してから決めてください。

プラン表記は変わる前提で

この記事に書いた価格と機能名は、すべて2026年8月時点で各社の公式ページに記載されていた表記です。AIコーディング分野は改定が頻繁で、半年前の記事の価格はほぼ当てになりません。契約前には必ず公式ページで最新の表記を確認してください。

もう1つ、社内で説明するときに効く整理を書いておきます。ツール費は、AIコーディングの費用のうち小さいほうです。実際に効いてくるのは、担当者が慣れるまでの時間と、確認作業の増加分です。月20ドルの見積もりで社内稟議を通すと、後で説明が苦しくなります。

非エンジニアが触れる領域

ここが本記事で最も相談が多い論点です。非エンジニアがAIコーディングに触れること自体は、まったく問題ありません。問題は、どこまで触るかを決めずに始めることです。

触ってよい3つの領域

プログラミングの経験がない方でも、次の3つは現実的に扱えます。

1. 自分だけが使う道具。手元のExcelやCSVを整形する、フォルダ内の書類から一覧を作る、といった作業。壊れても自分が困るだけで済む
2. 下書きを作る作業。手順書、仕様のメモ、社内向けの説明文。最終確認を人がする前提なら安全
3. 調べる作業。既存の社内システムについて「この処理はどこで行われているか」を読ませて説明させる。書き換えさせなければ何も壊れない

この3つに共通するのは、失敗しても被害が自分の範囲に収まることです。非エンジニアの入口は、必ずここから作ってください。詳しくはClaude Codeは非エンジニアでも使えるかで扱っています。

触れてはいけない領域

逆に、次の領域は判断できる人が同席していない限り触らないと決めてください。

• お金が動く処理。請求、単価計算、割引、在庫数。1桁の間違いがそのまま実害になる
• 個人情報や権限の判定。誰がどのデータを見られるかの条件は、間違っても画面上は正常に見える
• 止まると業務が止まる仕組み。受注、出荷、勤怠。試作の延長で本番に載せない
• 他社に提供するもの。納品物になった瞬間、責任の性質が変わる

この4つは「非エンジニアだから駄目」なのではありません。エンジニアであっても、1人で決めて1人で反映してはいけない領域です。線引きの理由が「経験の有無」ではなく「壊れたときの被害」にあることを、社内で共有してください。

判断できない状態がいちばん危ない

最も危険なのは、動いているものを見て「できた」と判断してしまう状態です。AIの出力は見た目が整っているため、正しさの確認をしないまま完成扱いになりやすい特徴があります。

この危険は、公的な調査でも間接的に裏づけられています。IPA「DX動向2026」によれば、AI導入・運用上の課題として「生成AIの効果やリスクに関する理解が不足している」が45.8%、「適切な利用を管理するためのルールや基準の作成が難しい」が39.7%を占めています。（出典：IPA「DX動向2026」。2026年7月30日公開、回収1,799社）

つまり多くの会社が、道具ではなく「判断の基準がない」ところで詰まっています。だから次の章の線引き表が必要になります。

AIに任せる／人がやる線引き

AIコーディングを社内で始めるとき、最初に作るべき文書はマニュアルではありません。線引き表です。A4半ページで構いません。

そのまま使える線引き表

責任の所在を先に決める

線引き表と同時に決めるべきは、「間違いが見つかったとき、誰が責任を持つか」です。AIが書いたから仕方ない、という説明は社外に対して通用しません。

この点は、道具の提供元も同じ立場を明示しています。Claude Codeの公式ドキュメントは承認前に安全性を確認する責任は利用者にあると明記していますし、（出典：Claude Code公式ドキュメント「Security」）Cursorの公式ドキュメントも、エージェントが設定ファイルを除くワークスペース内のファイルを承認なしで変更でき、変更は即座にディスクへ保存されると説明したうえで、変更を戻せるよう常にバージョン管理を使うことを推奨しています。（出典：Cursor公式ドキュメント「Agent Security」）

外部の会社と一緒に進める場合は、契約の型も関係します。作業の遂行を依頼するのか、完成物の引き渡しを求めるのかで責任の置き場所が変わるためです。この違いは準委任と請負の違いで整理しています。

速く書けると増える仕事

ここが、多くの記事が書かない部分です。AIコーディングを入れると、確実に増える仕事が3種類あります。先に知っておけば準備できますが、知らずに始めると「思ったより楽にならない」という感想で終わります。

レビューの総量が増える

1つ目はレビューです。生成される変更の量が増えれば、確認すべき量も増えます。書く人が1人でも、確認する人が1人しかいなければ、そこが詰まります。

典型的な詰まり方は、レビュー担当者が「読み切れないので、とりあえず通す」に変わることです。こうなると、AIを入れる前より品質は下がります。速さを上げる前に、確認の担当と手順を決めてください。

対策は3つあります。1回の依頼を小さく区切って差分を読める量に保つこと、レビュー型のツールで一次拾いを自動化すること、そして「人が必ず見る箇所」を線引き表で絞ることです。全部を同じ密度で見ようとすると破綻します。

検証と動作確認の負担

2つ目は検証です。AIが「できました」と言った状態は、動作確認済みという意味ではありません。ここを混同したまま本番に載せる事故を、当社は何度も見てきました。

効くのは、依頼文に確認方法を含める習慣です。「変更後にテストを実行して結果を報告して」と一言添えるだけで、AIが自分の出力を検証してから返すようになります。そもそも検証手段がない作業は、AIに任せる前に検証手段を作るのが先です。

承認疲れという落とし穴

3つ目は、あまり語られませんが実務では深刻です。エージェント型のツールは、危険な操作の前に承認を求めます。ところが承認を求められる回数が多いと、人は内容を読まずに承認するようになります。

この現象は道具の提供元も認識しており、Claude Codeの公式ドキュメントには、頻繁に使う安全なコマンドを利用者・コードベース・組織の単位で許可リストに登録できる仕組みが「prompt fatigue mitigation」として説明されています。（出典：Claude Code公式ドキュメント「Security」）

実務での対処は単純です。安全な操作は明示的に許可リストへ入れ、危険な操作の承認だけを残す。「面倒だから全部許可」に倒すのが、導入初期に最もやってはいけない設定変更です。

向いている仕事・向かない仕事

AIコーディングには、はっきりと得意・不得意があります。不得意な領域に投入して「使えない」と結論づけるのが、いちばんもったいない失敗です。

向いている5つの仕事

1. 既存コードを読んで説明させる。担当者が辞めた後の社内システムを理解する用途は、最も費用対の話を抜きにして効きます
2. 定型的な変換・整形。書式の統一、名前の一括変更、データ形式の変換など、正解が機械的に決まる作業
3. テストコードの作成。人が後回しにしがちで、かつ生成物の正しさを実行で確かめられる
4. 使い捨ての小さな道具づくり。1回きりの集計、一時的な変換スクリプト。壊れても被害が小さい
5. 古い言語や不慣れな領域の橋渡し。読める人が社内にいないコードの解読や、別の言語への書き換えの下書き

向かない4つの仕事

• 要件が決まっていない開発。何を作るか決まっていない状態で速く作ると、作り直しが増えるだけです
• 正解を検証できない処理。出力が正しいかを確かめる方法がないなら、速く作っても確認できません
• そもそもデジタル化されていない業務。紙・手書き・電話が起点の業務は、AIより先に入力の形を整えるのが順番です
• 複雑な業務ルールが暗黙知になっている領域。人の頭の中にしかない条件は、AIには渡せません

4つ目は特に中小企業で頻発します。「うちの受注は担当者が例外を判断している」という状態のまま自動化すると、例外の扱いだけが抜け落ちた仕組みができあがります。この場合は、AIコーディングより先に業務ルールの言語化が必要です。

中小企業が最初に使う場面

ここまでを踏まえて、中小企業が最初に手を付けるべき場面を具体的に示します。結論は「壊れても業務が止まらない、けれど毎月発生している作業」です。

最初の1つの選び方

次の3条件を満たす作業を1つだけ選んでください。

1. 毎月必ず発生している。年1回の作業では、慣れる前に忘れます
2. 結果の正しさを人が確かめられる。突き合わせる元データがある、または目視で判定できる
3. 失敗しても他部署や社外に影響しない。最初の1つで事故を起こすと、社内の合意が消えます

この条件に当てはまりやすいのは、月次の集計、複数ファイルにまたがる転記、フォーマット変換、社内向け報告書の下書きです。いきなり基幹システムの改修から始めないでください。

社内システムの小改修という入口

もう1つの現実的な入口が、社内システムの小さな改修です。項目を1つ増やす、画面の文言を直す、帳票のレイアウトを変える。外注すると見積もりと日程調整だけで数週間かかる規模の依頼が、社内で片づく可能性があります。

ただし条件があります。そのシステムがバージョン管理されていること、そして戻し方が分かっていることです。この2つがない状態で始めるのは、消しゴムを持たずに下書きするようなものです。業務に載せるものを作る工程はClaude Codeで開発するで詳しく扱っています。

保守費用との関係を先に考える

見落とされがちなのが、作った後の話です。AIで作ったものにも保守は発生します。むしろ、社内に詳しい人が1人しかいない状態で数を増やすと、保守の総量だけが積み上がります。

外注しているシステムの保守費用と、内製したときに自社が負う負担を並べて考えてください。判断材料はシステム保守費用の相場にまとめています。「作れるから作る」ではなく「持ち続けられるか」で決めるのが、中小企業では現実的です。

国内データで見る現在地

感覚論を避けるため、公表されている数字で現在地を確認します。ここは期待値を調整するための章です。

効果が出ている用途と割合

IPA「DX動向2026」によれば、AI導入による効果は「期待以上の効果があった」13.7%と「期待どおりの効果であった」18.1%の合計で31.8%、最も多いのは「一定の効果はあった」の50.6%でした。（出典：IPA「DX動向2026」／IPA プレスリリース「国内企業のDX動向・AI活用動向のポイントを公開」。2026年7月16日）

この数字の読み方が重要です。「効果はあったが、期待したほどではない」が半数という構図は、AIコーディングでも同じだと考えたほうが安全です。導入して劇的に変わるのは一部で、多くは「たしかに楽にはなった」という着地になります。

コード生成の効果は高いが3割は出ていない

用途別に見ると、コード生成は明るい部類に入ります。同報告書は、用途を導入効果別に見たとき「データ分析・予測・インサイト抽出」および「プログラムコードやシステム開発支援」は効果が出ている割合が高いとしています。

ただし同じ文で、この2つはともに「効果が出ていない」も3割弱あると明記されています。（出典：IPA「DX動向2026」図表3-10）

この「3割弱」を無視した記事が多すぎます。コード生成は効果が出やすい用途である。同時に、およそ3社に1社は効果を実感できていない。この両方が同じ調査に載っている事実を、導入判断の前提にしてください。

なお業種別では、「プログラムコードやシステム開発支援」を用途に挙げた割合は情報通信業が76.3%で他業種を大きく上回っています。IT企業以外では、まだ主戦場になっていない用途だという点も押さえておくべきです。

詰まっているのは人材とルール

効果が出ない理由も同じ調査から読み取れます。AI導入・運用上の課題は「専門人材が不足している」が50.1%で最多、次いで「生成AIの効果やリスクに関する理解が不足している」が45.8%、「適切な利用を管理するためのルールや基準の作成が難しい」が39.7%でした。

加えて、AIに関するポリシーやガイドラインを「どちらも定めていない」企業が16.7%、AIや生成AI独自のリスクマネジメントを実施している企業は14.2%にとどまっています。

企業規模の差も明確です。AIの導入状況は従業員1,001人以上の企業で8割近くが導入している一方、101人以下の企業では16.6%でした。中小企業はまだ入口に立ったところだという現実を、期待値の前提にしてください。

総務省「令和7年版 情報通信白書」でも、日本で何らかの業務に生成AIを使っていると回答した割合は55.2%、導入に際しての懸念事項の1位は「効果的な活用方法がわからない」で、中小企業では活用方針を「明確に定めていない」との回答が約半数を占めていました。（出典：総務省「令和7年版 情報通信白書」企業におけるAI利用の現状）

大企業の実例で見るコード生成

数字だけでは具体像がつかみにくいので、実際にコード生成を業務で動かしている例を2つ紹介します。出典はGoogle Cloudが公開している生成AIの顧客事例集で、同社の販促資料であり中立な調査ではありません。成果は各社の公表内容であり、掲載されているのは主に大企業です。

COBOL仕様書の再構築

1つ目は東京システムハウス株式会社の例です。同社はCOBOLシステムのモダナイゼーションを得意とする独立系IT企業で、ベテランエンジニアの引退にともなう人手不足と、システムのブラックボックス化が課題でした。

同社は自社が培ったCOBOLの知見をGeminiに盛り込んだ「AIベテランエンジニア」を開発し、既存のソースコードをアップロードするとフローチャートを含む仕様書を自動生成する「仕様書作成システム」と、新任エンジニアがチャット形式で質問できる「質疑応答システム」を用意しました。事例集には、COBOL仕様書30本を、プロンプト調整を含めて約1週間で再構築・復元することに成功したと記載されています。（出典：Google Cloud「生成AI 顧客事例集」。事例制作2025年7月）

注目すべきは「新しく作った」話ではない点です。読める人がいなくなったコードを、読める形に戻す。これはAIコーディングの中でも、中小企業の課題感に最も近い用途です。

古い言語の変換とテスト生成

2つ目は住友ゴム工業株式会社の例です。同社は1990年代から設計にデジタル技術を取り入れてきましたが、環境がレガシー化・複雑化し、異なる対応言語への習熟が壁になっていました。

同社はCloud Workstationsで開発環境を整えたうえでGeminiの利用を開始し、部門横断での検証を経て実用を開始。新規コード生成や、社内で使える人が少ない古い言語で作られた既存プログラムの言語変換に活用しています。事例集には、動作確認のための単体テストプログラムもGemini Code Assistに生成させていること、Fortranなどの古い言語で作られた既存プログラムをJavaなどの最新言語に変換していることが記載されています。（出典：Google Cloud「生成AI 顧客事例集」。事例制作2024年7月）

規模が違う点の注記

この2社の話を、そのまま自社に当てはめないでください。東京システムハウスはCOBOLのモダナイゼーションを事業としてきた専門企業で、住友ゴム工業は100年以上の歴史を持つ大手メーカーです。いずれも、AIに渡せる知見と、部門横断で検証できる体制を先に持っていました。

従業員数十名の会社がこの規模の成果をそのまま再現できる、という接続はしません。読み取るべきは数字ではなく用途の方向性です。「読める人がいないコードを読める形にする」「古い形式を新しい形式に変換する」という使い方は、規模に関係なく効きます。自社で始めるなら、対象を1本の帳票、1つのマクロに絞ることから始めてください。

深掘りモデルケース（試算）

ここからは数字で具体化します。以下は実在の企業の実績ではなく、当社が想定する典型的な状況にもとづくモデルケース（試算）であることを、はじめに明記します。

前提条件

業務別の試算表

この表の特徴は、減る仕事と増える仕事の両方を1枚に入れていることです。減る分だけを並べた試算は、現場の実感と合いません。

月24時間の削減は、時間単価2,500円で換算すると月60,000円分の時間にあたります。ツール費は個人向けプラン1名分で月20ドル程度です。当社の導入支援をご利用いただく場合の費用は初期0円・月額5万円です。

増えた仕事を必ず表に入れる

上の表で、増える側の合計は月13時間です。減った37時間の3分の1以上が、確認と記録に戻っていきます。これは失敗ではなく、正常な姿です。

むしろ、この13時間を計上していない導入計画のほうが危険です。確認と記録の時間を予定に入れていないと、その時間は「誰も担当していない仕事」になり、結局は省略されます。省略された結果が、半年後に「誰も直せないツール」として返ってきます。

試算どおりにならない3つの要因

1つ目は、対象業務の整い方です。上の表は、元データの形式がある程度そろっていることを前提にしています。同じ帳票が部署ごとに微妙に違う、手書きの補記が混ざる、といった状態では、削減率は大きく下がります。

2つ目は、立ち上げ期間です。上の表には、最初の1か月から2か月で担当者が試行錯誤する時間が含まれていません。導入直後はむしろ手間が増える期間があります。ここで「効果が出ない」と判断して止めてしまうのが、当社が見てきた中で最も多い離脱パターンです。

3つ目は、浮いた時間の使い道です。月24時間をどう使うかを先に決めていないと、時間は浮いているのに「何も変わっていない」という評価になります。残業を減らすのか、後回しにしていた改善に充てるのか、増員を見送るのか。導入前に決めておいてください。

よくある失敗と防ぎ方

当社がAI導入の相談を受ける中で、繰り返し見てきた失敗を5つ挙げます。すべて対策とセットです。

ツールを選ぶところから始める

最も多い失敗です。「どのAIコーディングツールがおすすめですか」から相談が始まると、たいてい選定に1か月かけて、導入後に使われません。

防ぎ方：先に「エディタを開く仕事が社内に週何時間あるか」を数える。ここが決まれば型が決まり、型が決まれば候補は2つか3つに絞られます。

一度に大きく任せる

「この機能をまるごと作り直して」と依頼して、数百行の差分が返ってきて手が止まるパターンです。差分が読めない量になった時点で、確認は実質不可能になります。

防ぎ方：1回の依頼を「1ファイル・1目的」に絞る。大きい作業は、先に計画を出させて計画を分割してから実行させる。

確認する人を決めていない

作る人だけ決めて、確認する人を決めないまま始めるパターンです。結果として作った本人が自分で確認することになり、思い込みがそのまま通ります。

防ぎ方：線引き表の「人が必ずやること」の欄に、役割ではなく名前を書く。1人しかいない会社なら、確認は翌日に回して時間を空けるだけでも効果があります。

秘密情報を読ませてしまう

顧客名簿、給与データ、認証情報が同じフォルダにあり、気づかないうちに読み込まれるケースです。読み込ませない設定はどのツールにもありますが、設定に書いたから絶対に安全、ということはありません。

防ぎ方：見せてはいけない情報は、そもそも作業フォルダに置かない。学習利用の設定を確認する。複数人で使うなら、管理者が組織全体に設定を強制する。

属人化して引き継げない

担当者1人がうまく使えるようになったものの、指示の型も設定も本人の頭の中にしかなく、異動や退職の瞬間に消えるパターンです。

防ぎ方：うまくいった指示文と、そう決めた理由を、プロジェクト内のファイルに残す。残す作業を「暇なときにやること」にしないのが要点です。前述の試算表で月5時間を計上したのは、このためです。

導入の進め方4ステップ

最後に、実際の進め方を4段階でまとめます。順番を入れ替えないでください。

ステップ1 対象を1つ選ぶ

毎月発生し、正しさを人が確かめられ、失敗しても社外に影響しない作業を1つだけ選びます。複数を同時に始めないこと。1つ目で型ができれば、2つ目からは速くなります。

ステップ2 線引き表を作る

本記事の線引き表をひな形に、自社版を作ります。項目は多くなくて構いません。「人が必ずやること」の欄に名前が入っていれば、最低限は成立します。

ステップ3 無料枠で1週間触る

3社とも無料枠があります。本番のファイルではなく、複製したフォルダで1週間触ってください。この期間の目的は成果ではなく、自社の仕事に合うかの判定です。

ステップ4 記録の置き場所を決める

成果が出始めたら、すぐに記録の置き場所を決めます。うまくいった指示文、決めた理由、動かない時の対処。ここまでやって初めて、AIコーディングは「個人の技」から「会社の仕組み」になります。

よくある質問（FAQ）

Q. AIコーディングとは何ですか

A. 生成AIにコードの作成・修正・説明を任せながら開発を進めるやり方の総称です。特定の製品名ではありません。任せる度合いによって「補完」「指示して書かせる」「丸ごと任せる」の3段階に分かれ、現在は3段階目のエージェント型が中心になっています。

Q. プログラミングの知識は必要ですか

A. なくても動かせますが、出力の良し悪しを判断する力はあったほうが安全です。知識がない状態でも、手元のファイル整形や下書き作成、既存コードの説明を読む用途なら現実的に扱えます。お金・個人情報・本番環境に関わる領域は、判断できる人が同席するまで触らないでください。

Q. どのツールから始めればよいですか

A. 「エディタを開く仕事が社内に週何時間あるか」で決めてください。週10時間以上あるならエディタ内で書く型、ほとんどないなら端末で丸ごと任せる型が入口になります。複数人で開発しているならレビューに使う型を追加します。

Q. 無料で試せますか

A. 試せます。CursorのHobby、GitHub CopilotのFree、ClaudeのFreeなど、主要な選択肢には無料枠があります。ただし利用量に制限があるため、業務で継続する場合は有料プランが前提になります。（出典：Cursor公式ヘルプ「料金とプラン」／GitHub Docs「Plans for GitHub Copilot」）

Q. 費用はどれくらいかかりますか

A. 2026年8月時点で、個人向けの入口は月10ドルから20ドル前後、上位プランは月60ドルから200ドル、法人プランは1席あたり月19ドルから120ドルという水準です。ただし本当に効いてくるのは、担当者が慣れるまでの時間と確認作業の増加分です。ツール費だけで見積もらないでください。

Q. AIが書いたコードの品質は信用できますか

A. 「文法的に正しい」という意味では高い水準ですが、「業務要件を満たしている」かは別問題です。金額の丸め方、日付の境界、権限の判定は静かに間違います。検証手段のない作業には使わない、というのが実務上の原則です。

Q. 責任は誰が負いますか

A. 利用者側です。Claude Codeの公式ドキュメントは、承認する前に提案されたコードとコマンドの安全性を確認する責任は利用者にあると明記しています。（出典：Claude Code公式ドキュメント「Security」）社外への納品物に関わる場合は、契約上の責任の置き場所も含めて事前に整理してください。

Q. 社内の秘密情報を読ませて大丈夫ですか

A. 読み込ませない設定は各ツールにありますが、設定だけに頼らないでください。見せてはいけない情報は作業フォルダに置かない運用が確実です。あわせて、学習利用の設定と、複数人で使う場合の管理者による強制設定を確認してください。

Q. 開発会社に頼まなくてよくなりますか

A. なりません。社内で片づけられる範囲は確実に広がりますが、止まると業務が止まる仕組みや、社外に提供するものは、体制と責任の引き受け手が必要です。判断の軸は準委任と請負の違いとシステム保守費用の相場にまとめています。

Q. どのくらい速くなりますか

A. 作業内容によって大きく違うため、一律の倍率は出せません。参考として、IPA「DX動向2026」ではAI導入による効果が「期待以上」または「期待どおり」と答えた企業は31.8%、「一定の効果はあった」が50.6%でした。（出典：IPA「DX動向2026」）「劇的に変わる」より「たしかに楽になる」を期待値に置くのが現実的です。

Q. 効果が出ない会社の共通点は何ですか

A. 3つあります。要件が決まっていないまま作り始めること、確認する人を決めていないこと、記録を残す時間を計画に入れていないことです。いずれも道具ではなく進め方の問題で、ツールを変えても解決しません。

Q. 非エンジニアが本番システムを触ってよいですか

A. 単独では触らないでください。本番反映、お金が動く処理、個人情報や権限の判定は、経験の有無にかかわらず1人で決めて1人で反映してはいけない領域です。読ませて説明させるだけなら何も壊れないので、そこから始めてください。

Q. エンジニアの仕事はなくなりますか

A. 中身が入れ替わります。打ち込む時間は減り、決める・確かめる・残すの比重が上がります。IPA「DX動向2026」でもAI導入・運用上の課題の1位は「専門人材が不足している」の50.1%で、判断できる人の必要性はむしろ高まっています。

Q. 何から相談すればよいですか

A. 「毎月発生していて、正しさを自分で確かめられて、失敗しても社外に影響しない作業」を1つ挙げるところからです。ここが決まると、必要な型と最初の一歩が自動的に決まります。判断に迷う場合は当社の無料相談をご利用ください。

まとめ｜任せ方を決める仕事

AIコーディングの全体像を、型・向き不向き・線引きの順で整理してきました。要点をまとめます。

• 変わったのは書く速さだけではない。読む・直す・引き継ぐの比重が上がった
• ツールは3つの型に収まる。エディタ内で書く／端末で丸ごと任せる／レビューに使う
• 選び方は製品比較ではなく「エディタを開く仕事が社内に週何時間あるか」で決まる
• 非エンジニアが触ってよいのは自分だけが使う道具・下書き・読ませて説明させる作業の3つ
• お金・個人情報・本番反映・社外提供物は、経験の有無に関係なく1人で決めない
• 速く書けるとレビュー・検証・記録の仕事が増える。試算表に必ず計上する
• IPA「DX動向2026」では、コード生成・システム開発支援は効果が出ている割合が高い一方、「効果が出ていない」も3割弱
• 中小企業の入口は「毎月発生し、正しさを確かめられ、失敗しても社外に影響しない作業」を1つ

AIコーディングは、コードを書く仕事を消す道具ではありません。「何をどこまで任せるかを決める仕事」を新しく増やす道具です。この決めごとを先に作った会社が、結果として速くなります。まずは無料枠で1週間、本番ではなく複製したフォルダで触ってみてください。

関連記事として、エディタで書く道具の手順はCursorの使い方、業務に載せるものを作る工程はClaude Codeで開発する、小さな道具づくりはAIでアプリを作る、任せる範囲の考え方はバイブコーディングとは、確認する側の話はAIコードレビュー、非エンジニアの関わり方はClaude Codeは非エンジニアでも使えるかをあわせてご覧ください。