
受託開発会社の経営方針転換:「作る会社」から「成果を出す会社」へ
私は受託開発会社を25年以上経営してきました。 当初は「納期を守って、品質よく作る」ことが正義でした。そこに疑いはありません。実際、それで会社は伸びました。 でも今、AIの普及で“実装コスト”が目に見えて下がっています。 コードを書く速さは…

EEG Editorial
Content Team
「AIを使うとセキュリティが危ないですよね?」 ここ最近、受託開発の現場でも経営の場でも、ほぼ毎週のように聞かれる質問です。 でも私は、少しだけ言い方を変えて返すようにしています。 AIはセキュリティに弱くない。弱いのは、人間の“気にする力”です。 AIが危険を呼び込むのではなく、人間が“気にしない”ことで危険が素通りする。 そしてAIは、良くも悪くもその姿勢を増幅します。 便利さに寄りかかれば、…
「AIを使うとセキュリティが危ないですよね?」
ここ最近、受託開発の現場でも経営の場でも、ほぼ毎週のように聞かれる質問です。
でも私は、少しだけ言い方を変えて返すようにしています。
AIはセキュリティに弱くない。弱いのは、人間の“気にする力”です。
AIが危険を呼び込むのではなく、人間が“気にしない”ことで危険が素通りする。
そしてAIは、良くも悪くもその姿勢を増幅します。
便利さに寄りかかれば、便利なまま事故ります。
慎重に扱えば、慎重さが加速します。
私はIT受託開発業界で25年以上、会社を経営してきました。
AI時代のパラダイムシフトは、開発の生産性だけでなく、「責任の所在」と「価値の源泉」を一段深いところで揺さぶっています。
今日はその中でも、とくに誤解されやすいセキュリティの話を、現場の体感も交えて書きます。
⸻
AIを使うと、たしかに“新しい失敗”が増えます。
• うっかり機密を貼り付ける
• それっぽいコードが出てきて、深く考えずに採用する
• 「このライブラリ古くない?」を見逃して突っ込む
• プロンプトに曖昧な要求を書いて、曖昧な危険を生成する
でも、冷静に見ればどれもAIの能力不足というより、人間の雑さです。
AIが勝手に金庫を開けて盗むわけではありません。
(AIは手がないので、盗めません。……今のところは。)
AIがやっているのは、基本的にこういうことです。
• 人間が求めた「速さ」と「それっぽさ」を最適化する
• 指示されなかったリスクは、指示されなかったまま出力する
• 期待された正解っぽさに寄せる(危険の匂いも含めて)
つまり、AIは「犯人」というより鏡です。
鏡に向かって「顔が疲れてるのは鏡のせいだ!」と言っても、疲れは取れませんよね。
必要なのは鏡を割ることではなく、生活習慣を整えることです。
セキュリティも同じです。
AIが弱いのではなく、私たちが “セキュリティを生活習慣にしていない” ことが弱点になります。
⸻
受託開発の現場で、セキュリティの話が出るタイミングにはパターンがあります。
• 仕様が固まったあとに、最後の最後で「セキュリティもお願いします」
• リリース前夜に、「これって大丈夫ですかね?」
• 事故が起きたあとに、「再発防止…」
これ、よくあるんですが、痛い。
なぜならセキュリティは基本的に、
「最後にちょっと塗るニス」ではなく、設計の骨格だからです。
家づくりで考えると分かりやすいです。
• 間取りが完成してから「耐震もお願いします」 → だいぶ無理
• 引き渡し前夜に「鍵って付けられます?」 → 付くけど、怖い
• 空き巣に入られてから「次は頑丈に…」 → そりゃそうだ
セキュリティって、尖ったハッカーと戦う話の前に、
「玄関の鍵を閉める」「鍵を玄関マットの下に置かない」みたいな基本が大半です。
そしてAI時代は、この「基本」をやる人とやらない人の差が、
これまで以上に綺麗に開いていきます。
⸻
AIで変わったのは、コードの書き方だけではありません。
受託開発の価値そのものが、こう移動しました。
• 以前: つくれること(実装力)
• 今: 正しくつくれること(設計力・検証力・運用力・責任)
AIがコード生成を高速化した結果、皮肉なことに、
「間違ったものを高速に作れる」時代にもなりました。
だからこそ、受託の価値はこれからますます、
• 要求の言語化(何を守るべきか、どこが境界か)
• リスクの見積もり(何が起きたら終わるか)
• 開発プロセスへの組み込み(仕組みで守る)
に寄っていきます。
セキュリティは、その中心にいます。
「ちゃんと作りました」ではなく、
「ちゃんと守れる形で作りました」が価値になる。
AIで“速さ”が均されるほど、責任を引き受けられる側が選ばれます。
そして責任は、最終的に人間に戻ってきます。
⸻
ここが今日いちばん伝えたいポイントです。
AIは“自分の信念”で安全になるわけではありません。
AIが安全側に寄るかどうかは、だいたい次の3つで決まります。\
難しいフレームワークより、まず効くのは習慣です。
おすすめは、AIとの会話のテンプレを変えること。
コードや設計を出させたら、次に必ずこれを続けます。
• 「この案のセキュリティ上の懸念を列挙して。優先度もつけて」
• 「誤用されるケース(悪用シナリオ)を3つ挙げて」
• 「最低限の対策セットを“今週中にできる順”で」
AIは、作るのも得意ですが、突っ込むのも得意です。
突っ込み担当を任せましょう。
社内に“厳しめのレビュー担当”が一人増えるイメージです。
AIに投げる前に、せめてこれだけは自分で書く。
• 守る対象:個人情報、売上データ、APIキー、顧客資産
• 脅威:内部不正、設定ミス、権限漏れ、外部攻撃
• 事故の定義:漏えい・改ざん・停止・不正送金など
セキュリティは、守る対象が曖昧だと、対策が装飾になります。
AIも同様で、「守る対象」を渡すと途端に賢くなります。
これは冷たいようで、実はAIにとっても優しい扱いです。
• 生成コードは必ずレビュー
• 依存関係はスキャン
• シークレット混入を検知
• テストと境界条件を追加
AIを信用しないのではなく、信用の仕方を設計する。
これがAI時代の成熟です。
⸻
個人の意識だけだと、忙しい日に崩れます。
崩れる前提で、組織は仕組みを作るべきです。受託ならなおさら。
「終わった」の定義に、最低限を含める。
• 認証/認可の確認
• ログと監査
• エラーハンドリング(情報漏えいしない)
• 依存ライブラリの脆弱性チェック
• シークレットの取り扱い
• セキュリティ観点のレビュー完了
これが入っていないと、AIが速くするほど、負債も速く積まれます。
人間の注意力は有限です。
AIの出力は無限に増えます。
なので、静的解析・依存性チェック・シークレットスキャンなど、
機械ができる部分は機械にやらせるのが現実解です。
AI時代に「目視で頑張る」は、竹槍で戦車に向かう感じになります。
勇ましいけど、やめましょう。
AIの「一般論」は便利ですが、受託開発では「御社のルール」が重要です。
• データ分類(どれが機密か)
• ログの残し方
• 権限設計の方針
• 使用許可ライブラリ
• インシデント時の手順
これらを整理し、AIが参照できるようにすると、
“セキュリティ意識の高いAI”が本当に育ちます。
ここで言う「育つ」は、AIが自我を持つという意味ではなく、
組織の知識がAI活用に乗って現場へ行き渡るという意味です。
⸻
セキュリティは、理想論ではありません。
受託開発では特に、競争力そのものです。
• 事故が起きない=信用が残る
• 仕様変更が起きても、境界が整理されていれば崩れない
• 監査・説明責任を果たせる=大きい案件に進める
• 何より、現場の疲弊が減る(これが大きい)
AI時代の現場は速いです。
速いからこそ、事故も速い。
だからこそ、「気にする」ことが最短ルートになります。
遠回りに見える“セキュリティの確認”が、最短です。
(道路工事の迂回路が、結局いちばん早かったみたいな話です。)
⸻
最後に、今日の話を一文にまとめます。
AIはセキュリティに弱くない。弱いのは、人間の無関心だ。
AIは、こちらが何を重視するかを、驚くほど正直に反映します。
だから、日々の会話で、日々の開発で、日々の判断で、
「安全も含めて価値だ」と言い続けることが重要です。
セキュリティは、恐れるためのものではなく、
安心して挑戦するための土台です。
AIは、その土台づくりを手伝ってくれる最高の相棒になれます。
ただし、相棒にしてくれるのはAIではなく、私たち人間です。
明日から、まず一つだけ変えましょう。
AIに何かを作らせたら、必ずこう聞く。
「これ、どこが危ない?」
その一言が、あなたのチームのAIを、そしてチームそのものを、
“守れる側”に育てます。