いまさら聞けない人のためのAIコーディング入門

AIコーディングツールが話題になってからしばらく経ちますが、その進化のスピードは衰えるどころか、むしろ加速しています。「なんとなく知ってるけど、ちゃんと使えていない」という方も多いのではないでしょうか。 すでに複数ツールを使いこなしている方も、仕事の制約で様子見中の方も、これからAX（AIトランスフォーメーション）を本格推進したい方も——それぞれの立場から、AIコーディングとどう向き合っていくのかを一緒に考えていきましょう。

https://www.youtube.com/watch?v=e8IkxquZ0YM

Transcript

1. いまさら聞けない人のための AIコーディング入門 日本仮想化技術株式会社 VirtualTech.jp 2026年06月03日 1
2. 生成AIとは 2
3. 生成AIとは 人間が与えた指示（プロンプト）に基づき、テキスト、画像、音声、動画、プログラム コードなどの新しいコンテンツを自動で生み出す人工知能 • 従来型AIとの役割の違い • 従来型AI： データの「識別」や「予測/分類」が主目的（例：画像の判別、売上動向の予測）。 • 生成AI： データを応用した「新たな成果物の出力」が主目的（例：文章の作成、プログラムの記述）。 • 処理可能なデータ形式（マルチモーダル） • テキスト： 報告書やメールの作成、要約、翻訳、アイデアの整理。 • コード： 多様なプログラミング言語の実装、リファクタリング、エラー検知。 • 画像・音声： 指定された条件に応じた図解や音声データの作成。 3
4. LLM（大規模言語モデル） 膨大なテキストデータを学習し、文脈に応じた自然な文章の理解や生成、多様な言語タス クを実行するAIモデル • 技術的な仕組み（計算と予測） • ニューラルネットワーク（Transformerアーキテクチャ）をベースに構築。 • 入力された文字列に対して、「確率的に最も自然に続く単語」を予測・出力する仕組み。 • 対応可能な業務 • テキスト処理： 報告書の要約、翻訳、仕様書やメールのドラフト作成。 • ロジック処理： プログラミングコードの記述、エラーの検知・修正。 • 構造化： 非構造なテキストデータからの情報抽出、JSONやCSV形式への変換。 4
5. ハルシーネーション AIモデルが、事実とは異なる、あるいは文脈と矛盾する情報を、あたかも正確であるかの ように出力する現象 • 発生の原因 • LLMは「事実の正しさ」を検証しているのではなく、「確率的に最も自然に続く単語」を予測して文章を 構成しているため。 • 学習データ自体の誤りや偏り、あるいは適切な情報が不足している場合に、整合性のみが取れた架空の記 述を出力してしまう。 • 主な発生パターン • 事実の誤認： 実在しない制度、法律、歴史的データ、統計数値を提示する。 • ソースの捏造： 存在しない書籍のタイトルや、架空のURLを根拠として出力する。 • コードの誤り： 正しそうに見えるが、実際には存在しないライブラリや関数を含んだプログラムを生成す る。 5
6. クラウド or オンプレ 6
7. クラウド型AI ChatGPT/Claude/Gemini など 7
8. クラウド型AIの特徴 インターネット経由で外部ベンダーのサーバーおよびAIモデルを利用する、現代の生成AI 運用の主流となるシステム形態 • 導入および維持管理コストの抑制 • AIの稼働に必要な高性能サーバー（GPUなど）を自社で保有・メンテナンスする必要がない。 • 月額のサブスクリプションや従量課金制が一般的であり、初期投資を低く抑えられる。 • 機能更新の即時性とメンテナンスフリー • AIモデルのバグ修正、セキュリティ対策、最新モデルへの移行などはすべて提供元（ベンダー）側で自動 的に実施される。 • ユーザー側は、常に最新の状態にアップデートされたAPIやインターフェースを即座に利用できる。 • 導入に気をつけておきたいこと • データ保護規約の確認： 入力したデータがモデルの再学習に利用されないよう、エンタープライズ（企業 向け）プランの選択、またはオプトアウトの設定が必要。 • インフラへの依存性： インターネットへの接続が必須であるため、通信障害時やオフライン環境、アクセ ス集中によるベンダー側のサーバー遅延時には利用できない。 8
9. クラウド型AIの特徴 9 AIサービス名 開発元 主な強み・特徴 得意なシチュエーション ChatGPT OpenAI 画像生成、音声会話、データ分析、高度 な推論など機能の豊富さ アイデア出し、画像・動画の生成、 Excelなどのデータ分析 Gemini Google Google検索との連携、動画・本丸ごとの 超長文読解 最新トレンドのリサーチ、GmailやDocs との連携、長い会議動画の議事録化 Claude Anthropic 人間らしく自然な文章作成、長文の論理 的解釈、プログラミング 提案書やメルマガの執筆、長文契約書 のチェック、システム開発の補助
10. オンプレミス型AI/エッジAI 10
11. オンプレミス型AI/エッジAIの特徴 外部のインターネットと遮断し、自社サーバー内やデバイスの内部でデータを完結させて 処理を行うAI運用形態 • ガバナンスとデータセキュリティの担保 • 特徴： 入力データや社外秘のソースコードが外部のネットワークに一切流出しない。 • 適したタスク： 厳格な個人情報の保護、未公開のコア技術開発、インフラ関連の機密データ処理。 • 導入における技術的トレードオフ • コスト： AIの稼働に必要な高性能ハードウェア（GPUなど）を自社で調達・管理・維持する必要があり、 初期投資が大きい • モデルの規模制限： 端末（エッジ）や自社サーバーの計算リソースに依存するため、クラウド型に比べて AIモデルのサイズ（パラメータ数）を軽量化が必要 11
12. 主要なモデル 12 モデルファミリー 開発元 日本語の強さ 主な特徴・得意なこと Qwen(クウェン) Alibaba(中国) 得意 ・日本語や中国語の処理能力が高い。 ・プログラミングやデータ分析などの実務能 力でもトップクラス。 Llama(ラマ) Meta(米国) 普通〜得意 ・オープンソース界の絶対的リーダーであり、 信頼性が抜群。 ・周辺のツールや開発コミュニティが最も充 実しており、導入しやすい。 DeepSeek (ディープシーク) DeepSeek(中国) 得意 ・高度な論理的思考が得意。 ・驚異的な低コスト・低負荷で動くため、開 発効率が非常に高い。 Gemma(ジェマ) Google(米国) 得意 ・Googleの最先端技術（Geminiの血統）を引き 継ぐ。 ・サイズが小さく軽量なため、ローカルPCや スマートフォンで動かしやすい。
13. LLMモデルの取得方法 • Hugging Face • AI・機械学習界のGitHub • 世界中の研究者や開発者が、自分が作ったAIモデル、学習用のデータセット、プログラムを投稿して共有 する、世界最大のオープンソースAIコミュニティであり、プラットフォーム • Ollama/LM Studioなど • 自分のパソコンやローカルサーバーにダウンロードして簡単に動かせるオープンソースのツール 13
14. モデル名の見方(Ollama編) モデル名 説明 <model名><バージョン> 例：qwen、llama、gemmaなど :<数字>b パラーメーター数を指す値で、推論能力の高さなどに影響 例：27b、35bなど -MLX Apple Silicon向けに最適化されたモデル 14
15. コンテキストウィンドウ AIが一度に記憶・理解できる「会話のキャパシティ（処理可能な情報量）」のこと • AIにとっての「短期記憶」の限界値 • 人間でいう「仕事中の机の広さ」のようなもの。 • コンテキストウィンドウが大きいほど、より多くの資料を机の上に広げて、それらをすべて見渡しながら 質問に答えることができる。 • 容量を超えるとどうなるか？（「忘却」の発生） • 制限を超えた過去の会話や古いデータから順番に、AIの記憶からこぼれ落ちて（忘れて）いく。 • 容量が小さいAIに長文を読み込ませると、文頭の指示を無視したり、ハルシネーション（嘘）を起こしや すくなったりする。 • ビジネス実務における重要性 • コンテキストウィンドウが小さいAI： 短いメールの作成や、一問一答のチャット向け。 • コンテキストウィンドウが大きいAI（Geminiなど）： 「分厚いPDFマニュアルを丸ごと読み込ませる」 「1時間の会議動画や数万行のコードを渡して分析させる」といった力技が可能。 15
16. トークンを理解しよう AIがテキストを処理・計算する際の「最小のパズルピース（基本単位）」 • 文字でも単語でもない「独特な区切り方」 • 人間は「文字（1文字）」や「単語（1単語）」で数えるが、AIは独自の辞書に基づいて文章を細かく分割 （トークン化）する。 • よく使う言葉は「1つの塊」として扱い、珍しい言葉は「さらに細かいパーツ」に分解して認識する。 • 日本語は英語より「損」をしやすい（文字数の目安） • 英語： 1単語 ＝ ほぼ1トークン（例：I have a pen. ＝ 4トークン） • 日本語： 1文字 ＝ 約1〜2トークン（ひらがな、漢字、カタカナが混ざるため細切れになりやすい） • ※そのため、同じ内容でも日本語で入力したほうが、AIの記憶容量を多く消費してしまう。 • ビジネスにおける重要性（コストと制限） • 料金の基準： 多くの商用AI（API）は「100万トークンあたり〇円」という、トークン単位の従量課金制。 • 制限の基準： 前述の「コンテキストウィンドウ（机の広さ）」の限界値も、文字数ではなく「〇万トーク ン」という単位で決まっている。 16
17. トークン化のイメージ(OpenAIの場合) 17 https://platform.openai.com/tokenizer
18. 自分に合うツールの選び方 18
19. 選び方のポイント • 自分のスタイルが定まってなければ、万能型の「 GitHub Copilot 」から始めてみる • ClaudeからChatGPT、Geminiなど主要モデルが使用できる • 自律度も調整しやすい(コード補完からチャット型、エージェント型まで) • クラウド型AIでは、Codex(OpenAI)、Claude Codeあたりが候補(あとGemini) • VS Codeの拡張機能で組み合わせることも可能 • 関心度が高まりつつあるのは自律型エージェント • テキストで指示するだけで開発できるのでニーズがある • 並行して複数プロジェクトを同時開発しやすいようなUIも出てきている • エディタレスなツールもあるので注意 • クラウド型AIがオーバースペックに感じるであれば、ローカルLLMも選択肢 • 能力的にも代替できるほど同等ではなく、コスト削減目的であれば候補になりにくい • 1周回って現状はクラウド型AIが月額は高めに感じるが、コスパで見るといいのかも 19
20. コーディングの流れ 20
21. これまでのスタイルとAI時代のスタイル プロセスのステップ 従来のスタイル AI時代のスタイル 要求分析・要件定義 必要な機能を箇条書きなどでリストアッ プ 要件のメモをAIに渡し、「この機能を作る 上で、考慮漏れしているケースはない か？」を洗い出してもらう 基本設計・詳細設計 画面遷移やデータの流れを考え、大まか な処理のステップを組み立てる。 AIが既存のコードベース全体を読み込み、 「どのファイルのどこを修正・新規作成す べきか」の具体的なステップを提示 タスク分割・実装準備 「まずはフォルダを作って、次にこの ファイルを書き換えて…」と、作業順序 を手動で整理 AIが提示したプランを人間がレビューし、 「その手順でOK」「いや、先にDBの処理 からやって」と軌道修正して確定させる コーディング 設計通りに、1文字ずつ関数やロジック を手動でタイピング 人間がプランを承認すると、AIが複数ファ イルを横断してコードを自動生成。人間は 差分確認 デバッグ・調整 動かしてみてエラーが出たら、該当箇所 を特定し、解決策を検索したりしながら、 自分でロジックを組み直す エラーが出た場合も「〇〇のエラーが出た のでプランを修正して」と指示し、自動で 原因特定と再修正を行わせる 21
22. 3つのモードの使い分け 22 モード AI（Agent）のやること 具体的な活用シーン Ask （質問・対話） 既存コードの解説、技術的な回答、エラー原因の提示。 ・「この関数は何をしてる？」 ・「このエラーの解決策は？」 ・「〇〇の実装方法の候補は？」 Plan （計画・設計） コード全体（文脈）を読み解き、修正が必要なファイルと手 順のリストアップ。 ・「新しく〇〇の機能を追加したいので、実 装計画を立てて」 Act （実行） エージェントとして、複数ファイルを横断してコードを自動 で書き換える。 ・「Planで合意した内容で、実際にコードを 書き換えて」
23. AIの能力を最大化する3つの アプローチ 23
24. プロンプトエンジニアリング AIモデルに対する指示文（プロンプト）の構造や記述方法を最適化し、出力の精度と安定 性を向上させる技術 • 目的と役割（出力の制御） • AIモデルに特定の役割や文脈（コンテキスト）を与えることで、タスクに応じた最適な回答を引き出す。 • 出力フォーマットをあらかじめ定義し、後続のシステムやプログラムで処理しやすい形式に固定する。 • 現在の位置づけ • 2026年現在の「Thinkingモデル（o1やGPT-5.5 Thinkingなど）」は、モデル自体が内部で思考プロセスを 自動実行するため、人間が長大なプロンプトを書く必要性は低下 • 現在のプロンプトエンジニアリングは、長文のテクニックよりも「いかに明確な制約条件とゴールを与え るか」というシンプルな要件定義の能力へとシフト 24
25. コンテキストエンジニアリング AIの記憶容量（コンテキストウィンドウ）を無駄遣いせず、関連データだけを厳選してAI に読み込ませる技術 • 目的と必要性（リソースの最適化） • 2026年現在のAIモデルは「一度に読み込める情報量」が大幅に拡大しているが、無関係なデータまで大量 に渡すと処理スピードの低下や、重要な指示の「見落とし」が発生 • AIに渡す情報を「今必要なデータ」だけに絞り込み、整理整頓してから入力するアプローチが必要 • 実務・開発における具体的なアプローチ • 人間側の工夫： チャット欄で @ファイル名 のように指定し、プロジェクト全体ではなく特定のコードだ けをピンポイントでAIの文脈（コンテキスト）に送り込む。 • システム側の工夫： ユーザーの質問に関係のあるソースコードの「関数」や「定義」だけを裏側でスマー トに収集・抽出してAIに手渡す。 25
26. MCP（Model Context Protocol） AIモデルと、外部のデータ（ファイルやデータベース）やツールを安全かつシームレスに 接続するための共通規格プロトコル • 開発の背景と目的（規格の標準化） • 米Anthropic社が提唱し、2026年現在、主要なAI開発ツールで採用が進むオープンな標準規格。 • これまではAIツールごとに異なっていた「ローカルファイルを読み込む」「データベースと連携する」と いったプログラムの接続方式を統一することを目的に開発された • 技術的な仕組み（クライアント・サーバー構成） • MCPクライアント： CursorやClaudeといった「AIを搭載したエディタやアプリ」 • MCPサーバー： GitHub、Slack、自社のデータベースなど「データを提供する側」 • クライアントとサーバーがMCPという共通言語（プロトコル）を介して通信することで、AIが自社データ を安全に読み書きできるようになる 26
27. RAG（Retrieval-Augmented Generatio） AIモデルの外部にある信頼できるデータベースから関連情報を検索し、その内容をAIに読 み込ませてから回答を生成させるシステム構成 • モデルが知らない領域の知識を補完 • AIモデル自身が学習していない「最新の動向」や「一般に公開されていない社内独自のデータ」について 質問された際、知ったかぶり（ハルシネーション）を起こすのを防ぐ。 • AIモデルのデータを直接書き換える（再学習させる）のではなく、回答に必要な「事実」をシステム側が 外部から調達して手渡すアプローチ。 • 基本的な処理の流れ • 検索（Retrieval）： ユーザーが質問した瞬間に、裏側のシステムが社内Wiki、仕様書、過去のコード資 産などから関連性の高いテキストを高速で検索・抽出する。 • 拡張（Augmentation）： 抽出したテキストを、ユーザーの質問文と一緒にAIへの指示（コンテキスト） に組み込む。 • 生成（Generation）： AIモデルは、手渡された信頼できるドキュメントの範囲内だけを読み、事実に基 づいた正確な回答を生成する。 27
28. 社内のAI活用について(雑談) 28
29. 日本仮想化技術株式会社 概要 • 社名：日本仮想化技術株式会社 • 英語名：VirtualTech Japan Inc. • 設立：2006年12月 • 資本金：3,000万円 • 本社：東京都渋谷区渋谷1-8-1 • 取締役：宮原 徹（代表取締役社長兼CEO）、伊藤 宏通（取締役CTO） • スタッフ：9名（うち、8名が仮想化技術専門エンジニアです） • URL：http://VirtualTech.jp/ • 仮想化技術に関する研究および開発 • 仮想化技術に関する各種調査 • 仮想化技術に関連したソフトウェアの開発 • 仮想化技術を導入したシステムの構築 • OpenStackやKubernetes、DevOps基盤の導入支援・新規機能開発 29 ベンダーニュートラルな 独立系仮想化技術の エキスパート集団 会社概要