誰もがコードを書ける時代が来たら？

AIや大規模言語モデル（LLM）によって、コードを書く人の範囲が大きく広がっています。かつては高度な技術知識が必要だったツールも、作りたいものを説明できれば誰でも使えるようになりました。この変化により、部門や職種を問わず、AIを使ってアプリケーションを作成し、タスクを自動化して、ビジネス上の課題を解決する「市民開発者」が新たに登場しています。

しかし、従来のセーフガードがないままコードを書く人が増えると、組織は新たな課題に直面します。確立されたプロセスの外で開発が行われると、セキュリティ、データガバナンス、監視の管理が難しくなります。偶発的なデータ漏えいからシャドーITの無秩序な拡大まで、リスクは現実のものです。

この変化を最大限に活用するには、セキュリティ、ガバナンス、管理を損なうことなく、新たな開発者たちを支援する方法が企業に必要です。

次の10億人の開発者に備える

開発者が10億人になるというのは大げさに聞こえるかもしれません。しかし、それはSFの世界というより、急速に現実になりつつあります。AIが参入障壁を取り払い、単発のスクリプトから趣味のプロジェクト、日々の業務まで、さまざまな目的でコードを書く人が増えています。

AIツールは、初心者を支援するだけではありません。経験豊富な開発者も、より難しい問題を解決し、作業を迅速化し、より価値の高い仕事に集中するために活用しています。ソフトウェアの書き方は進化しており、もはや正式な訓練を受けた人だけの仕事ではありません。

AIの進歩とともに、開発者と非開発者の隔たりは縮まりつつあります。これまで自分を技術者だと思っていなかった人々も、コードベースに貢献し、ワークフローを自動化し、実用的なツールを作るようになりました。こうした「市民開発者」の台頭は、ソフトウェアの作り方と、そのプロセスに関わる人々を変えています。

この変化は、組織に大きな問いを投げかけています。ほぼ誰もがコードを書けるようになったとき、ソフトウェア開発はどう変わるのでしょうか。また、開発能力が一部の専門家に限られなくなったとき、チームはどう適応すればよいのでしょうか。

市民開発者の2つのタイプ：専用プラットフォームと自然言語プロンプト

AIによって開発に携わる人が増えています。その方法は大きく分けて、専用プラットフォームと自然言語ツールの2つです。

多くの従業員が、ローコードや自動化のプラットフォームを使って社内ツールを作成したり、繰り返し行うタスクを効率化したりしています。Retool、n8n、Salesforceなどのツールを使えば、非開発者でもシンプルなインターフェースと最小限のコードで、データベースの連携やワークフローの作成、業務プロセスの自動化が簡単にできます。

Retoolを使うと、既存のAPIやデータソースを活用してチーム向けの社内アプリを作成できます。n8nはドラッグ＆ドロップのインターフェースで複雑なワークフローを自動化します。Salesforceでも、従来のコードを書くことなく、営業へのアプローチやマーケティングのフォローアップなどのCRMタスクを自動化できます。

こうしたツールを使えば、開発者やITチームの対応を待たずに作業を進められます。従業員が自ら問題を解決し、プロジェクトを加速させ、組織全体の時間を有効活用できます。ローコードツールの需要が高まり続ける大きな理由はここにあります。チームがより速く動く自由を得られるのです。

一方、別のユーザー層は、平易な英語からコードを生成するAIアシスタントを利用しています。GitHub CopilotやClaudeなどのプラットフォームなら、正式なトレーニングを受けていなくても、スクリプトの作成、データの整理、簡単な分析を簡単に行えます。やりたいことを説明すれば、あとはツールが処理してくれます。

このような環境は、本格的なアプリケーションではなく、迅速でシンプルなソリューションを必要とするチームに特に役立ちます。習得にかかる時間を短縮し、時間を節約するとともに、これまでエンジニアリング部門に限られていた業務に、より多くの人が貢献できるようになります。

こうしたツールによって、ソフトウェア開発に携わる人の裾野が広がっています。コードを簡単にするだけでなく、テクノロジーをより利用しやすく、包括的で、実験しやすいものにしています。しかし、新たな問いも生まれます。従来の開発者の役割はどうなるのでしょうか。そして、誰もがコードを書けるようになる中で、セキュリティをどう維持すればよいのでしょうか。

誰もが開発する時代、シャドーITも増えていく

AI生成コードやローコードプラットフォームの普及に伴い、シャドーITは急速に広がっています。従業員は、IT部門を介さず、自分たちでツールを作るようになりました。こうした自律性は生産性を高める一方、見えないところでリスクと複雑さを増大させます。

ツールは増える一方、可視性は不十分

チームが独自のアプリやワークフローを作成すると、IT部門はその仕組みや扱うデータ、セキュリティ対策を把握できないことが少なくありません。ツールごとに認証方式やデータの保存場所が異なったり、基本的なセキュリティチェックがまったく行われなかったりする可能性があります。その結果、インフラの管理が難しくなり、問題も見逃されやすくなります。

データの移動は速く、ときには安全策なしに行われます。

市民開発者は、実際の業務データ、顧客情報、財務情報、社内記録を扱うことがよくあります。適切なトレーニングや監視がなければ、善意の従業員であっても、誤ってコンプライアンス上のリスクを招いたり、機密データを漏えいさせたりする可能性があります。一貫したガバナンスがなければ、どのツールが基準を満たし、どれが満たしていないのかを把握するのは困難です。

支援の第一歩は、責任を共有すること

こうした問題を解決するために、すべてを禁止する必要はありません。適切に導くことが大切です。組織は、明確なセキュリティガイドライン、負担の少ない承認プロセス、安全な開発に役立つ実践的なトレーニングを提供できます。ITチームも、何が作られているかを追跡し、必要に応じて介入できるツールを備えるべきです。

イノベーションは、管理を手放すことではない

チームが自ら問題を解決できるようにすれば、より速く、創造的な成果につながります。ただし、自由には支援が伴うことが重要です。IT部門と他部門が連携すれば、イノベーションと強固なガバナンスを両立し、誰の足も止めずに安全に拡大できます。

ローコードAIプラットフォームを狙う悪意ある攻撃者

ローコードやAIを活用した開発プラットフォームの人気が高まるにつれて、攻撃者に狙われやすい標的にもなっています。こうしたツールの多くは、堅牢なセキュリティではなく、スピードと使いやすさを重視して設計されています。セキュアなデフォルト設定や監視のないまま、専門知識のない人がアプリケーションを作ると、脆弱性が入り込むおそれがあります。

ツールが増えればリスクも増える——特に開発に不慣れな人が使う場合

市民開発者は、セキュアコーディングの正式なトレーニングを受けていないことがよくあります。それは本人の責任ではなく、業務の範囲に含まれていないだけです。しかし、その結果、作成したツールには入力値の検証、認証、暗号化といった基本的な保護が欠けている可能性があります。攻撃者はそれを理解し、公開されたエンドポイント、設定ミスのあるアクセス制御、保護されていない状態で機密データを取り込むアプリなど、攻撃しやすい対象を積極的に探しています。

速く作る、ただし支援を受けながら

組織は市民開発者にセキュリティエンジニアのように考えることを期待できませんし、そうさせるべきでもありません。より効果的なのは、基本的なセキュリティ対策、既知の問題を検出する自動スキャン、安全な開発パターンなど、明確なガードレールを提供することです。定期的な監査や自動テストも役立ちますが、それだけですべてが解決するわけではありません。

セキュリティを障壁ではなく、みんなのスキルに

セキュリティトレーニングを厳格なものにする必要はありません。簡潔なガイド、組み込みのテンプレート、必要なタイミングで受けられる学習は大きな効果をもたらします。データの適切な扱い方や、共有ドキュメントにAPIキーを貼り付けるといった危険な行動の見分け方、自分が作るものの影響について従業員に教えましょう。

市民開発者を避けるのではなく、共に取り組む

最善の防御策は、連携です。ITチームとセキュリティチームが市民開発者を取り締まるのではなく、パートナーとして協力すれば、信頼関係が築かれ、より良い成果につながります。この連携が、不要なリスクを持ち込まずに、誰もが迅速かつ安全に開発できる基盤となります。

誰もがコードを書ける時代は、もう始まっている。問われるのは、組織がそれを安全に支えられるかどうかです。

市民開発者を支援することは、セキュリティの基準を下げることではありません。誰がソフトウェアを作り、どう管理し、どのような支援を行うかという考え方を変えることです。AIを活用したツールに適切なガードレール、トレーニング、連携を組み合わせることで、チームは管理を損なわずに開発を加速できます。

Snykは、市民開発者が作るツールからエンタープライズ向けアプリケーションまで、開発プロセスのあらゆる段階にセキュリティを組み込むことで、組織が変化を先取りできるよう支援します。

どこで作られるものでも、開発中のものからセキュリティ対策を始めましょう。

Snykの支援について詳しく見る。