「社内アプリを内製する前に」のタイトルバナー。中央に『便利さ ⇄ 統制』の天秤、左に個人/部門の作り手、右に情シス/管理側、下部に運用・セキュリティ・ライセンスの 3 本柱を配したモチーフ。

この記事の要点

  1. 社内アプリの内製は 速くて現場に合う 一方、統制・引き継ぎ・セキュリティ・ライセンス の代償が必ず付きます。「便利さ」と「統制」はトレードオフだと最初に直視するのが出発点です。
  2. 対象読者: 社内ツール / 業務自動化 / 部門 Web アプリを 作る側(個人・部門)、および 許可・管理する側(情シス・実務責任者) の双方。前提知識は不要です。
  3. 得られる成果: 「シャドー IT → 市民開発 → 内製」の グラデーションで自分の位置を測る + 公開範囲の 昇格パス表 + 運用・セキュリティ・ライセンスの 3 本柱(最低ライン) + 先送りすると痛い順 の公開前チェックリスト。
  4. 扱わないこと(専門部署へ): 個別アプリの可否の最終判断 / 自社のシャドー IT ポリシー(情シスへ)/ 個人情報の越境移転(法務・DPO へ)/ ネットワーク設計(企業ネットワークの仕組み)/ 通信の暗号化(通信セキュリティ)/ 依存ライセンスの各論(OSS ライセンスの見極め)。

Key Points (for international readers)

  1. Building internal apps in-house is fast and fits the field — but always at the cost of governance, handover, security, and licensing. Start by facing the "convenience vs. control" trade-off head-on.
  2. Who this is for: both the people building internal tools (individuals, departments) and those who approve and govern them (IT, business owners). No prior knowledge needed.
  3. What you get: place yourself on the shadow-IT → citizen-development → in-house gradient, an escalation-path table for exposure scope, the three pillars (operations / security / licensing) with minimum lines, and a pre-release checklist ordered by "what hurts most if deferred."
  4. Secure-development regulation differs by region (US procurement-driven SSDF; EU hard law via the CRA and revised PLD). That angle — including recent US shifts — is centered in the English edition — a companion piece, not a translation.

執筆時点: 2026-06 / 対象: 日本の社内アプリ内製(個人・部門・小チーム)/ last_updated: 2026-06-11 更新履歴: 2026-06-11 初版

本記事は教材であり、専門判断の代わりではない

社内アプリは、扱い方次第で 情報漏洩・法令違反・社内規程違反 に波及しうる領域に触れます(個人情報保護法 / / OWASP Top 10 級の脆弱性 / シャドー IT / AI 生成コードの規約違反 等)。本記事は 教育目的の一般的な整理 であり、特定の実装・事案への助言ではなく、内容の正確性・完全性・最新性を保証しません。本番判断は必ず 情シス / 情報セキュリティ部門・社内 法務 / DPO・セキュリティ専門家・AI 利用ガイドライン担当 に確認してください。本記事の情報は「現状有姿(AS IS)」で提供され、利用・信頼した結果生じたいかなる損害についても、執筆者および YATA-NODE は一切の責任を負いません。

本シリーズの位置づけ: 本記事は「社内で 作るアプリ側」の視点です。土台となる 企業ネットワークの仕組み・通信セキュリティ・仮想化とサンドボックス入門 と、依存の見える化 SBOM ツールの選び方・OSS ライセンスの見極め を前提に、その上で「作る / 許可する」の判断を扱います。各記事は 独立に読めます。

用語ミニ解説(はじめての方へ):

  • シャドー IT: 情シス・法務の管理外で、個人や部門が独自に使う/作るツールや SaaS。便利な一方、データ・契約・ライセンスの所在が見えなくなります。
  • 市民開発(citizen development): 業務側の非エンジニアが、会社が選定したローコード基盤(Power Platform / kintone / AppSheet 等)の 枠の中で アプリを作る動き。承認下にある点がシャドー IT と異なります。
  • 内製(in-house development): 情シス・開発組織が、統制下で自社サービス/基盤を作ること。
  • ゼロトラスト: 「社内ネットワークの内側だから安全」を前提にせず、すべてのアクセスを都度・最小権限で検証 する考え方(土台は 企業ネットワークの仕組み)。
  • SBOM(Software Bill of Materials): ソフトが使う部品(依存ライブラリ)の一覧。推移的依存(部品が呼ぶ別の部品)まで見える化し、ライセンス・脆弱性の把握に使います(詳細は SBOM ツールの選び方)。

内製は速いが「統制」と引き換え — メリット・デメリットの天秤

先に結論です。社内アプリの内製は、外注より速く現場に合う という強い利点と引き換えに、統制・引き継ぎ・セキュリティ・ライセンス の代償を必ず生みます。「便利さ」と「統制」は本質的にトレードオフで、これを最初に天秤として直視すると、以後の判断が速くなります。

内製のメリットとデメリットの天秤。左の皿にメリット(変更が速い・現場適合・低コスト・自走力)、右の皿にデメリット(統制不足・属人化・セキュリティ/ライセンスリスク・運用負荷の継続)を載せた図。

メリット(なぜ内製が選ばれるか)はおおむね 4 つです。

  • 速さ: 「発注 → 仕様調整 → 納品」の長いサイクルが消え、思いついたら数日で形になる。
  • 現場フィット: 業務を知る人が直接作るので、要件の齟齬が起きにくい。
  • コスト: 外注見積では割に合わない小規模ニーズを拾える。
  • 自走力: 担当部門が自分たちで改善でき、IT 部門の手待ちが減る。

一方の デメリット / リスク も、便利さの裏返しとして 4 つに整理できます。

  • 統制: 管理外で動く「シャドー IT」が増えると、データ・契約・ライセンスの所在が見えなくなる。
  • 属人化: 作った人がいなくなると誰も触れない(担当 1 人に依存する「バス係数 1」問題)。
  • セキュリティ / ライセンス: 入力検証の欠如・公開範囲のミス・条項未確認の素材組み込みで、1 人の事故が会社全体に波及 しうる。
  • 運用負荷: テスト・監視がないまま本番化すると、障害時に「何が起きたか分からない」状態が続く。

注意したいのは、経営・管理側と作り手の利害は完全には一致しない ことです。管理側は統制崩壊やインシデント時のレピュテーションを気にし、作り手は引き継ぎ責任や退職時のロックを背負います。だからこそ「やめるか・全部統制するか」の二択ではなく、便利さを活かしつつ最低限の統制を後付けできる形 に寄せるのが現実解になります。次章で、その「自分の位置」を測るところから始めます。

いま自分はどこにいるか — シャドー IT / 市民開発 / 内製のグラデーション

社内で作るアプリは、「シャドー IT か、ちゃんとした内製か」の二者択一ではありません。主体・承認・公開範囲・統制レベルが連続するグラデーション として捉えるのが実態に近く、まず「自分(自部門)の今の位置」を測るのが出発点です。

内製アプリのグラデーション図。横軸が公開範囲(個人→部門→全社→社外)、縦軸がガバナンス強度(個人判断→承認→IT 部門管理)。左下がシャドー IT、中央が市民開発、右上が内製開発として連続的に配置される。
区分主体承認統制典型例
シャドー IT個人 / 部門が独自になし外個人 PC の Python スクリプト、未承認 SaaS
市民開発業務側の非エンジニアあり(基盤選定済)中Power Platform / kintone 上のローコードアプリ
内製情シス / 開発組織あり内自社 Web サービス、社内基盤

ここで現実的に重要なのは、シャドー IT は自然に発生する ということです。情シスの応答が遅い・既存基盤が現場に合わないとき、業務側は「自分で作る」を選びます。これを頭ごなしに禁止しても地下化するだけなので、承認下のローコード環境(= 市民開発)に取り込む のが管理側の現実的な打ち手になります。

公開範囲の「昇格パス」を逆算する

内製アプリは「自分用ツール → 便利だから部門で共有 → 部門ツール化 → 全社で使われる」と 昇格 しがちです。各段階で 次に進むなら何が要るか を逆算しておくと、後追い対応の代償が減ります。

規模公開範囲統制負荷次段に進むなら最低限
個人ツール自端末低(機密扱い注意)ドキュメント、シークレット管理
小チーム共有部門内 / VPN 内中+ 認証 + バックアップ + 運用手順書
部門アプリ部門 / 関連部門中〜高+ 申請承認、SSO 連携、ログ集約
全社アプリ全社高+ 監視 + アラート + 監査ログ + 災害対策
社外公開インターネット最大+ WAF + ペネトレーションテスト + インシデント対応体制

管理・承認する側(情シス・実務責任者)の読みどころはここです。部門の内製を「許可するか / 昇格させるか / 止めるか」は、上の表で どの段に上がろうとしているか で決まります。個人ツールに全社並みの統制を求めれば芽を摘み、社外公開に個人ツールの統制しか無ければ事故になる。段に見合った最低ラインを条件として渡す のが、芽を潰さずに統制する近道です。作り手側も、自分が次の段へ上がる前に同じ表で「足りないもの」を自己申告すると、許可が早くなります。

作るなら最低限の 3 本柱 — 運用・セキュリティ・ライセンス

どの段にいても、稼働するアプリを支えるのは 運用・保守 / セキュリティ / ライセンス の 3 本柱です。1 本欠けても柱として機能しません。完璧を目指す必要はなく、まず 「最低ライン」を満たし、段が上がったら「中級ライン」へ 引き上げるのが現実的です。

社内アプリを支える 3 本柱の図。運用・保守 / セキュリティ / ライセンス・性能・ログ の 3 本の柱が『稼働するアプリ』の屋根を支え、1 本欠けると傾く構造を示す。

柱 ① 運用・保守性 — 「作った人がいなくなっても回る」ための最低限です。

  • コードを Git に置く + README に「何を・なぜ・どう動かす」を書く(属人化対策の起点)。
  • スモークテスト 1 本(/health チェック)+ Lint / Format の自動化。
  • 監視は /health + アラート 1 本 から。中級では Metrics / Logs / Traces の三層へ。

柱 ② セキュリティ — 「社内だから安全」を捨てるところから始めます(後述のゼロトラスト)。

  • 入力検証(許可リスト方式)、SQL は パラメータ化クエリ、XSS は 文脈別エスケープ。
  • データ最小化: 集めない・出さない・残さない。機密(パスワード / トークン / PII)を ログに出さない。
  • 公開範囲の区別: localhost と 0.0.0.0 を意識し、/admin や .env を本番に露出させない。
  • 認証認可: パスワードはハッシュ化し 会社 SSO に乗せる、可能なら MFA。
  • AI 生成コード: 学習元コードの混入やライセンスに注意し(利用中の AI 開発支援ツールに「公開コードと一致する出力を抑制/検出する機能」があれば有効化)、機密をプロンプトに入れない。SCA / SAST・ライセンス確認を CI に組み込める と中級です。

柱 ③ ライセンス・性能・ログ — 後で「実は混入していた」が一番痛む領域です。

  • 直接依存のライセンスを確認し、可能なら 推移的依存まで で網羅(各論は OSS ライセンスの見極め と SBOM ツールの選び方 へ)。
  • 性能: 早すぎる最適化を避け、計測してから直す。本番化前に P95 応答や月次コストの目標を置く。
  • クラウドコスト: 予算アラート + 停止忘れ防止(TTL タグ / 自動削除)。停止忘れで月数万〜数十万円に達した事故事例もあります(個人検証用 GPU の消し忘れ等)。

アプリ自身もゼロトラスト前提で

ゼロトラストはネットワーク側だけの話ではありません。アプリ自身も「社内 LAN だから安全」を前提にしない 必要があります。過去には、空調ベンダー経由の侵入や委託先の認証情報盗用など、「境界の内側に入れば全部見える」前提が崩れた大規模事例が繰り返されてきました。米国立標準技術研究所(NIST)の「ゼロトラスト・アーキテクチャ」指針(NIST SP 800-207)は複数の原則(tenets)で整理されていますが、実装観点で 3 点に要約すると ①すべてのリソースを保護対象として扱う ②すべての通信を(ネットワーク位置によらず)認証・暗号化する ③アクセスはセッションごとに最小権限で評価する になります。アプリの実装に落とすと、DB 接続ユーザを読み取り / 書き込み / 管理用に分ける、API トークンを用途別 + scope 最小で発行する、「1 度ログインしたら永続的に信頼」にしない、といった具体策になります(ネットワーク側の土台は 企業ネットワークの仕組み)。

海外市場・取引が絡むときだけ視野に入れること

社内限定のツールなら国内の考え方で足りますが、自社製ソフトを EU 市場へ製品として出す・海外取引先や海外子会社に提供する 瞬間に、海外の規制が「自社の開発プロセスへの要求」として降りてきます。代表が EU の サイバーレジリエンス法(CRA) と 新・製造物責任指令(PLD)、米国の セキュア開発フレームワーク(NIST SSDF) です。求められる中身(セキュア開発・脆弱性管理・SBOM による依存の可視化)は地域共通で、本記事の 3 本柱の延長線上にあります。法域別の詳細は 英語版 で扱います。

公開前に — 先送りすると痛い順 + チェックリスト

最後に、公開(または次の段へ昇格)する前のチェックです。経験則として、後段で発覚するほど修正コストが跳ね上がる 項目があります。順に潰しておくと後悔が減ります。

  1. データ分類(計画段階で確定しないと、機密が一般ログに混入する設計になる)
  2. 認証認可の入れ場所(後付けでガードを足すとアプリ全体に手が入る)
  3. ライセンス方針(後で「実は が混入」が発覚すると配布停止 / 再実装)
  4. 公開範囲の設計(localhost で作って 0.0.0.0 で動かし、意図せず全社公開は事故の典型)
  5. ログレベル設計(全部 INFO で書いた後の整理は地獄)
  6. 退職時の所有権移管(担当者退職後に発覚すると、権限の取り戻しに月単位)

下のチェックリストは、公開前の自己診断にそのまま使えます(全部に「はい」が要るわけではなく、自分の段に必要な分 を満たせば十分です)。

text
【公開前チェックリスト(社内アプリ)】
□ 計画: データ分類を確定し、扱う個人情報・機密の範囲を文書化した
□ 計画: 情シス / 情報セキュリティ部門のガイドラインを確認した
□ ライセンス: 直接依存・推移的依存のライセンスを(可能なら SBOM で)確認した
□ ライセンス: AI 生成コード・素材(画像・フォント)の利用規約を確認した
□ セキュリティ: 入力値検証(許可リスト方式)を実装した
□ セキュリティ: SQL はパラメータ化クエリ、XSS は文脈別エスケープを実装した
□ セキュリティ: 認証・認可を「社内だから」で省略していない(SSO / MFA)
□ セキュリティ: 公開範囲を意識し、/admin や .env 等の露出がない
□ セキュリティ: 機密(パスワード / トークン / PII)をログに出していない
□ 運用: README に目的・起動手順・連絡先を最低限書いた
□ 運用: コードを Git に置き、退職時の所有権移管手順を整理した
□ 運用: 最低 1 本のスモークテスト(/health チェック)がある
□ 性能: 性能目標(P95 応答 / 同時利用者数 / 月次コスト上限)を設定した
□ 性能: クラウド予算アラートを設定し、TTL 管理ができている

軸はこの 3 つに尽きます。① 便利さと統制はトレードオフ(二択でなく、段に見合う最低ラインを後付けする)、② 自分の段をグラデーションで測り、昇格パスを逆算する、③ 運用・セキュリティ・ライセンスの 3 本柱を、まず最低ラインで揃える。土台の 企業ネットワークの仕組み・通信セキュリティ・仮想化とサンドボックス入門 と、依存の見える化 SBOM ツールの選び方・OSS ライセンスの見極め を合わせると、「作る / 許可する」の判断が一段速くなります。

出典 / References

社内アプリのセキュア開発・運用は、公的な標準・ガイドラインが指針を示しています(版・適用日は経時改定されるため、内容は執筆時点 2026 年 6 月の整理です)。

このシリーズでは、企業ネットワークの仕組み・通信セキュリティ・仮想化とサンドボックス入門・SBOM ツールの選び方・OSS ライセンスの見極め も扱っています。あわせてどうぞ。

AI 補助の透明性: 本記事は、執筆者が実務で把握していた論点をもとに、調査・整理・要点化の補助として Claude(Anthropic)を用い、その上で執筆者が一次情報(公的標準・行政ガイドライン)を確認して構成しました。標準・ガイドラインの版や適用日は執筆時点(2026 年 6 月)での整理です。

著者について

大手電機メーカーで制御工学から 20 年以上の電機・ソフトウェア開発、加えて個人開発 約 10 年の実務経験を持ちます。ハードとソフト、企業と個人の両面で「知らないとリスクになる」基礎から発信し、いずれは AI の実践的な活用法なども扱っていく予定です。詳しくは このブログについて。