AIコーディング入門
第2回:プロンプト以外で効率化!開発体験の改善手法

Share

Security NEWS TOPに戻る
バックナンバー TOPに戻る

AIコーディング2アイキャッチ(AIコーディングの効率化の手法と課題)

生成AIを使ったコーディングでは、プロンプトエンジニアリングが効率化の王道として知られています。しかし実際には、RAG(検索拡張生成)やファインチューニングといった手法を組み合わせることで、さらに精度や体験を向上させることが可能です。本記事では、これらの技術の概要とAIコーディングにおける活用例、そして共通して立ちはだかる品質・性能・セキュリティの課題とその解決の方向性を解説します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

プロンプトエンジニアリング以外の効率化手法

プロンプトエンジニアリングは、手軽に(安価に)試せる生成AIの体験の改善や効率化の手法として位置づけられています。そして、プロンプトエンジニアリング以外でも生成AIの効率化や体験の改善、特定の目的のための調整などができる手法としてファインチューニングRAG(Retrieval-Augmented Generation)があります。以下の図はそれぞれの手法を簡単にまとめたものです。

図 1 プロンプトエンジニアリング、RAG、ファインチューニングの概要

AIを使ったコーディング(以下AIコーディング)でもこの3つの手法は生成コードの改善や生成プロセスの効率化のために用いられます。また、企業や組織でのコーディングに際しては、個人レベルでの作業でのプロンプトエンジニアリング、内部レポジトリやAPIドキュメントとの結合による効率化を行うRAG、コーディング規約やスタイルなどの品質管理などを目的としたファインチューニングというように、目的別に同時並行で使うことができます。

AIコーディング全般に共通する課題

AIコーディング自体は一般的といえる領域に入りつつあります注 1) が、一方でAIコーディング全般に共通する課題として、大きく分けて以下の3つの課題が挙げられます注 2)

ロジックの不整合

  • 小さなコードであれば問題にならないことも多いですが、大きなコードになればなるほど、コード内のロジックで不整合が発生することが増えます
  • プロンプトで与えられているビジネス上の目的を正しく解釈できない場合、期待されない出力をする可能性もあります

メモリなどのボトルネックに対する配慮の欠如

実行環境に関する配慮がないため、メモリを予想以上に使用するコードや、処理パフォーマンスに配慮しない出力が出てくることが往々にしてあります

セキュリティへの配慮の欠如

  • セキュリティに対して前出のような配慮事項を指示しない限りは配慮が欠如していることが多くあります
  • 仮に配慮事項の指示を行っても不正確・セキュアでない出力が出される確率も一定程度残存します

品質とセキュリティを守るプロセス設計

AIコーディングが進化してもなお、人の手にゆだねられているものがあります。それは「何のためにコーディングするのか」「コードを使ってどんな業務をして、その結果として何を得るのか」といったビジネス上の目的を設定することと、コードが正確に動作することやセキュリティ上問題がないことを確認するプロセスを設けることです。コードの品質やセキュリティに関するプロセスは通常、ソースコード診断でセキュリティの確認を行うことが一般的です。

最近ではDevSecOpsの一環として、コード開発中にSAST(Static Application Security Testing)ツールをCI/CDパイプラインに統合するケースも増えてきています。また、完成品に対するテストとしてDAST(Dynamic Application Security Testing)を実行することも必要でしょう。これはWebサイトであればWebアプリケーション診断が該当します。


―第3回「AIエージェント時代のコーディング:MCPとA2Aとは」へ続く―

注:
1)2024年5月に実施されたプログラマー・エンジニアを中心としたコミュニティであるStackOverflowによる調査では開発にAIを利用すると回答したプロフェッショナルの開発者は63.2%でした。
2)CSET “Cybersecurity Risks of AI Generated Code” (Jessica Ji, Jenny Jun, Maggie Wu, Rebecca Gelles, November 2024)

【参考情報】

【連載一覧】

―第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」―
―第2回「プロンプト以外で効率化!開発体験の改善手法」―
―第3回「AIエージェント時代のコーディング:MCPとA2Aとは」 ―
―第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」―
第5回「AIとセキュリティ:Non‑Human Identity とAIエージェントの課題
第6回「AIエージェントのセキュリティ対策と今後の展望


Security NEWS TOPに戻る
バックナンバー TOPに戻る

ウェビナー開催のお知らせ

  • 2025年9月3日(水)13:00~14:00
    止まらないサイバー被害、その“対応の遅れ”はなぜ起こる?~サイバー防衛の未来を拓く次世代XDR:大規模組織のセキュリティ運用を最適化する戦略的アプローチ~
  • 2025年9月10日(水)14:00~15:00
    フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 2025年9月17日(水)14:00~15:00
    サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─
  • 最新情報はこちら


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    前倒しで対処 -セキュリティを考慮したソフトウェア開発アプローチ「シフトレフト」とは-

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    シフトレフトとは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。ソフトウェアの開発工程の各フェーズにおいてセキュリティが組み込まれていないと、後工程での手戻りが発生し、修正コストもかかってしまいます。本記事では、シフトレフトによるメリットや開発におけるセキュリティ対策の実施例について解説いたします。

    シフトレフト(Shift Left)とは

    セキュリティにおける 「シフトレフト(Shift Left)」 とは、より早期の段階でセキュリティに関する問題に対処する、ソフトウェアの開発や運用の考え方です。元々この概念は仕様を満たしているか等の検証に対するソフトウェアテストのジャンルで使われていた言葉ですが、近年セキュリティの世界で注目されています。

    ソフトウェア開発の主要工程である「設計」→「開発」→「検証」→「運用」の各プロセスは、計画書や図などで、通常左から右に向けて記載されます。図の左側(レフト)、すなわち時間軸の早い段階で脆弱性を作り込まない対策を施した開発を行えば、セキュリティリスクを低減させるだけでなく、品質向上、期間短縮、トータルコスト低減などの効果があります。

    セキュアなWebアプリケーション開発を推進する国際NPO「OWASP(Open Web Application Security Project)」もシフトレフトを推奨しており、Googleをはじめとする先進IT企業ではこの考え方を採用したシステム開発を行っています。

    シフトレフトの考え方

    シフトレフトの考え方では開発工程からセキュリティ診断を組み込むことで、スケジュールに与える影響を最小限に、また計画的かつ定期的に実施頂くことで費用面、人材面のコストを抑えつつセキュリティの堅牢性向上を見込むことができます。

    「要件定義」や「設計」等の上流工程の段階からシステム運用までの各フェーズで、セキュリティへの配慮を取り入れることが、より安全なシステムを構築するうえで重要となります。

    セキュリティを開発の最終段階で対応したのではすでに遅く、開発プロセスの全フェーズにおいて常にセキュリティ上の課題を先取りして解決しながら進めることが、テストやリリースといった最終段階での手戻りを防ぎ、結果的にトータルコストの削減と品質の向上に寄与します。

    「シフトレフト」と「セキュリティ・バイ・デザイン」「DevOps」「DevSecOps」との違い・関係

    シフトレフトと関連する言葉に、「セキュリティ・バイ・デザイン」「DevOps(デブオプス)」「DevSecOps(デブセックオプス)」などがあります。

    「セキュリティ・バイ・デザイン(SBD:Security by Design)」とは、開発の企画・設計段階からセキュリティを考慮することです。

    「DevOps(デブオプス)」は、ソフトウェア開発チーム(Developer)と運用チーム(Operations)が互いに協力し合い、ソフトウェアとサービスのクオリティを向上させます。「DevSecOps(デブセックオプス)」は、開発チームと運用チームに、セキュリティチーム(Security)が加わり、セキュリティを含めトータルコストを低減しつつ、さらなるクオリティ向上を実現する仕組みです。

    セキュリティ・バイ・デザインは概念、DevSecOpsは体制運用、そしてシフトレフトは工程管理の考え方ですが、いずれも、事故やトラブルが起こってから、あるいは脆弱性が見つかってから、といった事後対応のセキュリティ対策ではなく、事前対応、すなわち前倒しで実践する点で一致しています。

    シフトレフトによって向上する品質

    たとえば、ビルを建てた後になってから、建物の基礎部分に問題が見つかったら改修は容易ではありません。また、社会的な信頼も大きく損なうことでしょう。ソフトウェアも同じで、問題発見が早いほど、改修に必要な労力、費用、時間は少なくてすみますし、信用失墜の危険性も軽減できます。

    リリース直前の脆弱性診断でWebアプリケーションに脆弱性が発見されたら、手戻り分のコストがかかるだけではなく、リリース日の遅れや、機会損失の発生を招き、ステークホルダーのビジネスにまで影響を及ぼしかねません。シフトレフトの考え方でセキュリティに配慮しながら開発を進めれば、こうしたリスクを低減でき、ソフトウェアの信頼度が高まります。

    シフトレフトによるトータルコスト低減メリット

    セキュリティに配慮せず開発を行えば、短期的にはコストを抑え、開発期間を短くすることができるでしょう。しかし、リリース後の運用過程で、もしサイバー攻撃による情報漏えいや知的財産の窃取などが起こったら、発生した損失や対応費用など、長期的に見たコストはより大きくなるでしょう。

    こうしたトータルコストの低減効果こそ、シフトレフトによるセキュアな開発および運用の真骨頂です。

    シフトレフトとは、発生しうるトラブルに事前に備えるということです。病気にならないように運動をしたり、食生活に気をつけたりといった、ごくごくあたりまえのことです。

    つまり、これまでのソフトウェア開発は、その当たり前をやっていなかったとも言えます。シフトレフト、セキュリティ・バイ・デザイン、 DevSecOpsという言葉がいろいろな場面で見られるようになったことは、開発現場が成熟してきた現れでもあります。今後、こういった開発プロセスが新常識となっていくことでしょう。

    シフトレフトを普及させた裁判の判決とは

    ここで、セキュリティ視点でのシフトレフトの考え方を日本に普及させるきっかけのひとつになったとされる、2014年の、ある裁判の判決をご紹介します。

    とある企業の開発依頼で納品されたオンラインショッピングのシステムに、SQLインジェクションの脆弱性があったことで、不正アクセスによる情報漏えい事故が発生しました。依頼した企業は、開発会社がセキュリティ対策を怠っていたことを債務不履行として提訴、東京地方裁判所がそれを認め、開発会社に約2200万円の損害賠償支払いを命じました( 平成23年(ワ)第32060号 )。ただし、全面的に開発会社の落ち度としたわけではなく、発注会社側が責務を果たしていない点については、相当程度の過失相殺を認めています。

    この判決は、これまで技術者がいくらセキュリティの必要性を説いても首を縦に振らなかった、セキュリティよりも利益を重視していた「開発会社の経営管理層」と、セキュリティよりもコストと納期を重視していた「発注者」の考えを変えるインパクトを持っていました。

    将来事故が起こらないよう、トータルコストを抑えセキュリティに配慮した開発を行う有効な方法としてシフトレフトが採用されたのは、ごく自然なことといえるでしょう。

    シフトレフトに基づく開発におけるセキュリティ対策の実施例

    シフトレフトに基づく開発におけるセキュリティ対策の実施例は以下のとおりです。

    ●セキュリティ・バイ・デザイン
    まず、セキュリティ・バイ・デザインの考え方に基づいて、企画・設計段階からセキュリティを考慮しましょう 。

    ●セキュアな開発環境
    開発は、脆弱性を作り込まないようにするフレームワークやライブラリなど、セキュアな開発環境を活用して行います。

    ●ソースコード診断
    開発の各段階で、プログラムコードに問題がないかを適宜検証するソースコード診断を実施します。

    ●脆弱性診断
    もし、どんなセキュリティ要件を入れたらいいかわからなくても、独立行政法人情報処理推進機構(IPA)などの専門機関がいくつもガイドラインを刊行しています。「このガイドラインを満たすような開発を」と依頼して、それを契約書に記載しておけばいいでしょう。ガイドラインの中身を完全に理解している必要はありません。

    リリース前や、リリース後の新機能追加等の際には、必ず事前に脆弱性診断を行います。また、脆弱性が悪用された場合、どんなインシデントが発生しうるのかを、さらに深く検証するペネトレーションテストの実施も有効です。

    シフトレフト視点での発注の仕方

    シフトレフトは主に開発者側の考え方です。では、ソフトウェア開発を依頼する発注者はどうすればいいのでしょうか。

    まず、発注の際には必ずセキュリティ要件を入れましょう。納品されたシステムやWebアプリケーションにセキュリティの問題が発見された際に対応を要求しやすくなります。

    もしそれによって見積額が上がったら、トータルコストのこと、シフトレフトというこれからの新常識のことを思い出していただきたいと思います。

    ・安全なウェブサイトの作り方(IPA)
    https://www.ipa.go.jp/security/vuln/websecurity.html

    シフトレフトの実現に向けて

    とはいえ、今回ご紹介したシフトレフトの考え方が社会に広く普及するまでには、もう少し時間がかかりそうです。

    システムライフサイクルの早い工程(シフトレフト)でのセキュリティ対策の実施例の一つに、「ソースコード診断」があります。

    実装工程でソースコードに作り込んでしまった脆弱性を検出するのが、「ソースコード診断」です。ソースコード診断では、他の種類の脆弱性診断では検出しづらい潜在的な脆弱性を、
    開発ライフサイクルのより早い工程で洗い出すことが可能です。他の脆弱性診断に先駆けて実施されるべき診断と言えます。

    セキュアコーディングを実践しつつ、ソースコード診断を効率的に行うためには、自動診断ツールを利用するのも有効です。静的コード解析を行うソースコード診断ツールの選定においては、以下のような点がポイントとなるでしょう。

    SQAT.jp を運営する株式会社ブロードバンドセキュリティが、リリース直前のWebサービスに脆弱性診断を行うと、山のように脆弱性が発見されることがあります。

    その脆弱性の中には、2014年の裁判で開発会社の債務不履行とされたSQLインジェクションのような、極めて重大なものが含まれていることも多くあります。

    業界が成熟し、シフトレフトによるセキュリティ対策が実践されていけば、脆弱性診断というサービスの位置づけ自体が将来変わることすらあるかもしれません。たとえば自動車のような、安全規格に基づいて設計製造された製品における出荷前の品質チェック、あるいは監査法人による会計監査のように、「きちんと行われている前提」で実施する広義のクオリティコントロール活動の一環になるかもしれません。

    SQAT.jp は、そんな未来の到来を少しでも早く実現するために、こうして情報発信を行い続けます。

    まとめ

    ・シフトレフトとは上流工程でセキュリティを組み込み、トータルコストを抑えるという考え方
    ・セキュリティを考慮せずにWebサービスを開発し提供するのは、たとえるなら建築基準法を考慮せずにビルを建ててテナントを入居させるようなもの
    ・セキュリティをコストととらえ費用を惜しむと、将来的により高い出費を余儀なくされる可能性がある
    ・シフトレフトによるセキュリティ対策には、セキュリティ・バイ・デザイン、セキュリティ要件の明示、セキュアな開発環境、早期段階から適宜に実施する各種セキュリティ診断等がある

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    セキュリティトピックス動画申し込みページリンクへのバナー画像