「競合他社がアプリを出したから、うちも検討してほしい」 上司からの突然の指示に、期待よりも不安を感じていませんか？ Webサイトやシステムの改善経験はあっても、アプリ開発は全くの別物です。 実際にプロジェクトが始まると、「多額の費用をかけたのに誰も使わない」「予期せぬ不具合でリリースが延期になる」「運用コストだけが膨らんでいく」といった失敗が後を絶ちません。 実は、アプリ開発の失敗要因はエンジニアの技術力不足だけではありません。多くの場合、開発が始まる前の「準備不足」や、リリース後の「運用設計の欠如」といった、発注者側のリスク管理に原因があります。 アプリは「作って終わり」ではなく、ユーザーに「使われ続けること」が成功のゴールです。 そこで今回は初めてアプリ開発を担当する方が絶対に知っておくべき「よくある失敗12選」とその対策を、工程別に詳しく解説します！ この記事を読めば、落とし穴を事前に回避し、社内調整から開発会社との交渉まで、主導権を持ってプロジェクトを進められるようになるはずです。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼アプリ開発の基本について知りたい方はこちら▼ アプリ開発とは？種類・流れ・必要スキル・費用感まで初心者向けにわかりやすく解説 初めてのアプリ開発はなぜ失敗しやすいのか アプリ開発の失敗は「開発前・開発中・リリース後」に起きる 開発前： 目的の整理不足 開発中： 品質管理の不備 リリース後： 運用・保守体制の欠如 アプリ開発における失敗は、エンジニアの技術力が足りなかったり、開発会社に問題があったりする場合だけに起こるものではありません。 実は、プロジェクト全体を俯瞰すると、開発前の目的整理が不十分だったり、開発中の品質管理に隙があったり、あるいはリリース後の運用体制が考慮されていなかったりと、複数のフェーズにおける不備が重なり合って失敗を招くことがほとんどです。 特に初めてプロジェクトを任された担当者の場合、開発会社へ正式に相談する前に、自社側で何をどこまで決めておくべきかの判断が難しく、準備不足のまま見切り発車してしまうケースが少なくありません。 アプリは「完成して公開すること」が成功ではなく、その後ユーザーに「使われ続けること」が本来のゴールです。 この視点が欠けてしまうと、多額の投資をしたにもかかわらず、誰も利用しないシステムが残るという最悪の事態を招きかねません。 リスクを最小限に抑えるためには、各工程で潜んでいる落とし穴を事前に理解し、先回りして対策を講じる姿勢が求められます。 失敗の多くは開発着手前の準備不足から始まる アプリ開発の成否を分ける最大の要因は、実はプログラミングが始まる前の企画段階にあります。 なぜこのアプリを世に送り出す必要があるのか、誰が抱えているどのような悩みを解決する手段なのか、そしてリリース後にどのような流れでユーザーに活用してもらうのか。 これらの根幹となる問いが曖昧なままプロジェクトを動かしてしまうと、開発の中盤で大きな仕様変更が発生したり、発注側と開発側の認識に致命的なズレが生じたりします。 一度開発がスタートしてから方向性を修正しようとすると、追加の費用が発生するだけでなく、開発期間の大幅な延長や、設計の無理な変更による品質低下を招くリスクが急激に高まります。 こうした事態を避けるためには、企画の段階でビジネス上の最終的なゴールを明確にし、想定ターゲットや利用シーンを具体化しておくことが不可欠です。 また、成功を測定するためのKPIや、最低限必要な機能を整理しておくことで、社内関係者や開発会社との意思疎通が円滑になり、プロジェクトの迷走を防ぐことができます。 初心者が特に注意すべき失敗パターン ・機能を欲張りすぎて予算・納期が破綻する ・自社都合を優先し、ユーザーの使いやすさ（UX）を軽視する ・テスト工程を削り、不具合を残したままリリースする ・リリース後の集客やOSアップデート対応を考慮していない 初めてアプリ開発に携わる方が陥りやすい典型的な失敗パターンには、いくつかの共通点があります。 まず最も多いのが、目的を絞り込めないまま見切り発車し、あれもこれもと欲張って必要以上に機能を詰め込みすぎてしまうことです。 機能が増えればそれだけ開発コストや不具合のリスクが増大し、結果として使い勝手の悪いアプリになってしまいます。 また、ユーザーの視点に立った使いやすさ、いわゆるUXを軽視して自社都合の設計を優先することも、リリース後の離脱を招く大きな原因です。 さらに、発注者側が開発会社に丸投げの姿勢をとってしまうと、完成間近になって「イメージと違う」といった認識の不一致が露呈します。 これに加え、テスト工程の期間を十分に確保せず不具合を残したままリリースしたり、セキュリティ対策や将来的なデータ拡張性を後回しにしたりするケースも、後に深刻なトラブルを引き起こします。 そして意外と盲点なのが、リリース後の集客施策や不具合修正、OSアップデートへの対応といった運用保守の計画を立てていないことです。 これらの要素を一つひとつ事前にチェックし、計画に盛り込んでおくことが、プロジェクトを成功へ導く鍵となります。 開発前によくある失敗と対策 失敗1：アプリを作る目的が曖昧なまま進めてしまう 対策：「既存会員の継続率を10%改善する」など、具体的な数値目標を言語化し、社内と開発会社で共有する。 アプリ開発において最も避けたい失敗は、プロジェクトの根本となる目的がぼやけたまま走り出してしまうことです。 「競合他社がアプリをリリースしたから」「社内のDXを推進するよう指示があったから」「なんとなく便利そうだから」といった抽象的な理由だけで開発を始めると、プロジェクトの途中で判断基準を失い、必要な機能や成功の定義が定まらなくなります。 目的が曖昧なプロジェクトは、機能の追加や修正が際限なく発生しやすく、結果として開発費用と運用コストだけが膨らみ、当初期待していた事業成果を全く得られないリスクが非常に高いといえます。 この失敗を未然に防ぐための対策として、開発に着手する前に自社が抱えている具体的な課題を洗い出し、アプリを通じて何を解決したいのか、どのような数値目標を達成したいのかを明確に言語化しておく必要があります。 例えば「既存会員の継続率を現状から10%改善する」「店舗への来店頻度を月平均2回から3回に高める」「カスタマーサポートへの問い合わせ対応工数を3割削減する」といった、具体的かつ測定可能な目標を立てることが重要です。 このように目的を数値化して定義しておくことで、社内での合意形成がスムーズになり、開発会社に対しても説得力のある説明ができるようになります。 失敗2：要件定義が不十分で「思っていたものと違う」アプリになる 対策：ワイヤーフレームやユーザー行動シナリオを用い、視覚的に認識を合わせる。 開発が始まってから「こんなはずではなかった」という後悔が生まれる原因の多くは、要件定義の不足にあります。 発注者側が「この業界なら当然こう動くはずだ」と考えている暗黙の了解や業務ルールは、ITの専門家である開発会社には一切伝わらないものだと認識すべきです。 特に仕様書に明記されていない細かい画面遷移、ユーザーの権限設定、特殊な業務フローなどは抜け漏れやすく、これが後の手戻りや品質低下を招く大きな要因となります。 こうした認識のズレを解消するためには、要件定義の段階でワイヤーフレームや画面遷移図、具体的なユーザー行動シナリオを活用し、視覚的にイメージを共有しながら議論を進める対策が有効です。 また多くの担当者が見落としがちなのが、正常に動作している「通常時」以外の挙動確認です。 入力ミスがあった際のエラーメッセージの表示、必須項目が未入力の場合の処理、電波が届かない通信不良時の対応、あるいは複数のアカウントで同時にログインしようとした際の挙動など、例外的なケースについても細かく確認しておく必要があります。 これらを事前に詰めておくことで、開発の主導権を握りつつ、堅実なシステム構築が可能になります。 失敗3：機能を詰め込みすぎて予算超過・納期遅延を招く 対策： MVP（実用最小限の製品）を定義し、検証に必要な最小限の機能に絞ってリリースする。 初めてアプリ開発を主導する際、理想を追求するあまり「競合アプリにある機能はすべて網羅したい」「将来的に必要になりそうな機能も今のうちに入れておこう」と考え、機能を際限なく膨らませてしまう傾向があります。 これはプロジェクト管理においてスコープクリープと呼ばれ、開発工数の増大、大幅な納期遅延、そして予算の枯渇を招く極めて危険な兆候です。 機能が増えれば増えるほどシステムは複雑になり、テスト項目も指数関数的に増加するため、最終的なアプリの品質にも悪影響を及ぼしかねません。 このリスクを回避するためには、MVP（実用最小限の製品）という概念を取り入れ、アプリの核となる価値を検証するために「最低限必要な機能」が何かを厳格に定義することが重要です。 企画会議などで新しい機能案が出た場合には、その機能が本当にリリース時に必須なのかを吟味し、もし追加するのであれば、代わりに既存のどの機能を次フェーズに回して全体のバランスを保つかといった、スコープ総量の管理を徹底してください。 優先順位を明確にすることで、限られた予算と期間内で確実に成果を出す体制を整えることができます。 失敗4：アプリで解決すべき課題と開発手法が合っていない 対策： 予算だけでなく、将来の拡張性や市場投入スピードを考慮して手法を選定する。 アプリの開発には、ゼロから構築するフルスクラッチのほか、既存の枠組みを利用するノーコードやローコード、Webとアプリの利点を組み合わせたハイブリッド型など、複数の手法が存在します。 これらはそれぞれ費用、カスタマイズの自由度、開発期間、将来の拡張性において大きな違いがあります。 陥りやすい失敗は、開発手法の特性を理解せず、単に提示された見積価格の安さだけで選んでしまうことです。 その結果、リリース後に機能拡張をしようとした際にシステム上の制約で不可能だと判明したり、逆にシンプルな目的のアプリに対して過剰な開発費を投じてしまったりする事態が起こります。 適切な手法を選ぶための対策として、まずはアプリの目的、必要な独自性、予算の限度、そしていつまでに市場へ投入したいかというスピード感を比較検討してください。 初めての挑戦であれば、最初からすべての機能を完璧に作り込むフルスクラッチを目指すのではなく、まずはスピード重視で最低限の機能を実現し、ユーザーの反応を見ながら段階的に機能を追加していくアプローチも非常に有効です。 自社のビジネスモデルや将来の展望に合致した手法を選択することで、無駄な投資を抑え、持続可能なプロジェクト運営が実現します。 開発中によくある失敗と対策 失敗5：UXを軽視して「使いにくいアプリ」になる 対策： プロトタイプの段階で想定ユーザーからフィードバックを得て、直感的な操作導線を確保する。 どれほど高度な機能が備わっていても、利用者が目的の情報にたどり着けなかったり、操作に迷ったりするアプリは、すぐに使われなくなります。 特にスマートフォンの画面は限られているため、会員証の表示やクーポンの利用、購入履歴の確認、予約といった主要な機能へ直感的にアクセスできない設計は致命的です。 こうした使い勝手の悪さは、ユーザーのストレスを増大させ、最終的にはアプリのアンインストールという最悪の結果を招きます。 このリスクを回避するためには、開発の早い段階で利用シーンを具体的に想定し、画面遷移の導線や情報の表示速度、デザインの一貫性を徹底的に確認することが重要です。 単に頭の中で考えるだけでなく、ワイヤーフレームやプロトタイプを作成し、実際の操作感を確認できる状態にしてください。 そのうえで、社内の関係者や想定ターゲットに近いユーザーからフィードバックを得る機会を設けることが対策として有効です。 早い段階での軌道修正は、開発終盤での大幅な作り直しを防ぐことにもつながります。 失敗6：テスト不足のままリリースして不具合が多発する 対策： 実機テストやパフォーマンステストを含めた「リリース判定基準」を事前に定め、品質管理を徹底する。 プロジェクトの納期が迫ってくると、真っ先に削られやすいのがテスト工程です。 「主要な機能は動いている」「開発会社が確認したと言っている」といった楽観的な判断でリリースを強行すると、現場では想定外のトラブルが頻発します。 アプリは利用者の端末の種類やOSのバージョン、不安定な通信環境、アクセス集中による負荷など、多種多様な条件下で使用されるため、限定的な確認だけでは不十分です。 不具合の多いアプリという印象が一度ついてしまうと、失った信頼を取り戻すのは容易ではありません。 対策としては機能テストやUIテストに加え、実際の端末を用いた実機テスト、修正の影響を確認するリグレッションテスト、さらにはパフォーマンステストやセキュリティテストを計画的に盛り込む必要があります。 また発見されたバグをどのように管理し、誰が修正を確認して、どのような基準を満たせばリリースを許可するのかという「リリース判定基準」を事前に定めておかなければなりません。 品質管理を開発会社任せにせず、発注者側もチェック体制を整えることが、安定した運用の第一歩となります。 失敗7：セキュリティ対策を後回しにする 対策： 設計初期から暗号化や権限管理を組み込み、機密情報を扱う場合は第三者による脆弱性診断を検討する。 個人情報や決済情報、認証情報を取り扱うアプリにおいて、セキュリティ対策の不備は企業の信用を根底から揺るがす重大な問題です。 多くのプロジェクトで陥りがちなのが「まずは動くものを作り、セキュリティは後で強化しよう」という考え方ですが、これは非常に危険です。 セキュリティはシステムの基礎設計に深く関わるため、後付けで対策を行おうとすると、大幅なプログラムの改修が必要になり、多大なコストと手戻りが発生します。 万全を期すためには、設計の初期段階からユーザー認証の仕組み、アクセス制御、通信の暗号化、データベースの保護、権限管理、脆弱性診断などを組み込んでおく必要があります。 特に決済機能や機密性の高い会員情報を扱う場合には、リリース前に第三者機関による専門的な脆弱性診断を受けることも検討すべきです。 セキュリティリスクを「いつか対処すべき課題」ではなく「開発の前提条件」として捉えることで、社内調整や予算確保においても説得力のある説明が可能になります。 失敗8：データ設計・分析基盤を後回しにして改善できなくなる 対策： 主要指標（KPI）を計測するためのログ設計を、開発段階で実装しておく。 アプリはリリースして終わりではなく、そこから改善を繰り返して成長させていくものです。 しかし、リリース後に「なぜユーザーが離脱しているのか」「どの機能が最も使われているのか」を把握するための計測設計がなされていないケースが散見されます。 ユーザー行動のログやコンバージョン率、DAU（1日あたりの利用者数）、MAU（月間利用者数）、継続率といった指標が可視化されていなければ、次に打つべき施策の根拠が得られず、場当たり的な改善に終始することになります。 この状況を避けるためには、開発に入る前から取得すべきデータ項目や分析したい指標、計測ポイントを明確にし、管理画面や分析ツールとの連携を設計に盛り込んでおく必要があります。 データベースの構造は後から変更しようとするとシステム全体に影響を及ぼすため、将来的な機能拡張や詳細なデータ分析を見越した柔軟な設計が求められます。 「リリース後にどのようなデータを見て判断したいか」をあらかじめ定義しておくことで、事実に基づいたPDCAサイクルを回し、事業成果に直結するアプリへと育てていくことができます。 リリース前後によくある失敗と対策 失敗9：ストア審査への準備不足でリリースが遅れる 対策： 開発初期から各ストアの審査要件を確認し、経験豊富な開発会社の知見を活用する。 アプリ開発において、リリース直前の大きな壁となるのがストア審査です。 App StoreやGoogle Playの審査でリジェクト（拒絶）されると、修正から再申請、再審査まで数日、場合によっては数週間を要するため、予定していたプロモーション開始日やリリース日がずれ込む事態を招きます。 主な原因としては、プライバシーポリシーの記述不備、課金フローがガイドラインに沿っていないこと、デザインガイドライン違反、あるいはメタデータ上の機能説明と実際のアプリの動作が一致していないことなどが挙げられます。 この失敗を避けるための対策として、開発初期の段階から各ストアの審査ガイドラインを熟読し、必要な表示項目やユーザー権限の説明、利用規約、スクリーンショットの仕様などを整理しておくことが重要です。 また、開発会社を選ぶ際にも、直近でのストア申請や審査対応の経験が豊富であるかを確認してください。 審査の傾向は頻繁に変わるため、最新の動向を把握している専門家の知見を借りることで、スムーズな公開が可能になります。 失敗10：リリース後の運用計画がなく放置される 対策： 障害対応フローを策定し、保守・運用費をあらかじめ予算に組み込んでおく。 アプリは「公開して終わり」ではありません。 リリース直後から不具合の修正、ユーザーからの問い合わせ対応、予期せぬシステム障害への対応、さらにはOSのアップデートに伴うメンテナンスといった継続的な業務が発生します。 これらの運用計画が曖昧なままプロジェクトを進めると、いざ問題が発生した際に「誰が状況を検知し、誰が修正を判断し、いつまでに対応を完了させるか」が決まっておらず、現場が混乱してユーザーの信頼を大きく損なうことになります。 対策として、リリース前から具体的な運用体制や保守契約の内容を固めておく必要があります。 障害対応フローや問い合わせ窓口の設置はもちろん、新しいOSがリリースされた際のアップデート対応、定期的な機能改善のサイクルをあらかじめ設計してください。 この際、初期の開発費用だけでなく、月々の保守・運用費も予算に含めて社内承認を得ておくことが、プロジェクトを安定して継続させるための重要なポイントです。 失敗11：集客・継続利用の施策を考えず、使われないアプリになる 対策： ASO（ストア最適化）や広告、プッシュ通知の運用方針をリリース前から計画する。 多額の費用をかけてアプリを開発しても、ストアに公開しただけで自然にユーザーが増えることは稀です。 SNS活用やWeb広告、メルマガ、店頭での告知、ダウンロードキャンペーンなど、既存会員への案内を含めた初期集客の設計が欠かせません。 また一度ダウンロードしたユーザーに使い続けてもらうための施策も不可欠です。 プッシュ通知は強力なツールですが、配信頻度や内容を誤ると、ユーザーに不快感を与えて通知オフやアンインストールを加速させてしまうリスクも孕んでいます。 効果的な対策は、ASO（アプリストア最適化）の実施や、初めてアプリを起動した際の導線設計、プッシュ通知の運用方針などを、開発が完了する前から計画しておくことです。 どのようなタイミングでユーザーに再訪を促し、どのような体験を提供すれば継続して利用してもらえるのかをリリース前から議論してください。 初期集客と継続利用の施策が組み合わさって初めて、アプリはビジネスの武器として機能し始めます。 失敗12：KPIを決めず、成功・失敗を判断できない 対策： 継続率や購入率など、ビジネスゴールに直結する指標を定義し、PDCAを回せる体制を整える。 ダウンロード数さえ伸びていれば成功だと考えがちですが、それだけではアプリが真に事業へ貢献しているかを正しく評価できません。 例えば、ダウンロード数が多くても継続率が極端に低ければ、そのアプリはユーザーにとって価値がないことになります。 目的に応じて、アクティブユーザー数、コンバージョン率、購入率、来店頻度、会員化率、解約率といった多角的な指標（KPI）を設定しなければ、次に行うべき改善の方向性を見失ってしまいます。 この失敗を防ぐためには、ビジネスゴールから逆算して「どの指標を改善すれば成功と言えるのか」を事前に定義することが不可欠です。 対策として、設定したKPIを正確に測定するために必要なデータ計測の仕組みや分析環境を、開発段階でしっかりと組み込んでください。 事実に基づいたデータを確認できる体制を整えることで、社内に対してもプロジェクトの成果を説得力を持って説明できるようになり、次の投資や改善に向けた合意形成が容易になります。 初めてのアプリ開発で失敗しないための進め方 まず「アプリである必要性」を確認する プロジェクトを本格的に動かす前に、そもそもなぜWebサイトやLINE公式アカウント、既存の業務システムではなく「アプリ」でなければならないのかを再確認することが不可欠です。 アプリ開発はWebサイト構築と比較してコストや保守運用の難易度が高くなる傾向にあるため、独自の強みを活かせる場面でなければ投資対効果が合いません。 アプリの最大の強みは、ユーザーの手元へ直接届くプッシュ通知、詳細な顧客行動データの蓄積、既存顧客のロイヤリティ向上、さらにはカメラや位置情報を活用したオフラインとのスムーズな連携にあります。 こうしたアプリならではの特性が、自社の抱えている課題解決と合致しているかを慎重に見極めてください。 もし「情報の閲覧」が主目的であればWebサイトで十分な可能性もあり、逆に「毎日使ってもらう仕組み」や「店舗と連動した体験」を提供したいのであれば、アプリは非常に強力な武器となります。 この「アプリであるべき理由」が社内で明確になっていれば、上司や関係部署への説明にも一貫性が生まれ、プロジェクトの軸がぶれるリスクを大幅に減らすことができます。 開発前に整理すべきチェック項目 目的とターゲット： 誰の何を解決するか MVP定義： 最小限必要な機能は何か 予算と保守： リリース後の維持費も含んでいるか 体制： 誰が不具合や改善を判断するか 失敗を未然に防ぐためには、開発会社への相談前に自社内で検討すべき事項が多岐にわたります。 まずはアプリ開発の目的と解決したいユーザー課題、想定される利用シーンを具体化し、競合アプリとの差別化ポイントを整理してください。 そのうえで、初期リリースで実装すべき最小限の機能（MVP）と、将来のアップデートで追加する機能を切り分け、予算とスケジュールの現実味を持たせることが大切です。 さらに、品質を担保するためのテスト方針やセキュリティ要件、効果測定のためのデータ計測・分析方針も事前に決めておく必要があります。 ストア申請に必要な準備や、リリース後に不可欠な運用・保守体制、ユーザーを獲得し継続利用してもらうための集客施策についても、この段階で網羅的にチェックしてください。 そして、何を達成すればプロジェクトが成功したと言えるのか、具体的なKPIを設定しておくことで、開発から運用までの各工程で迷いのない判断が可能になります。 開発会社を選ぶときの確認ポイント 開発パートナーの選定はプロジェクトの成否を左右する極めて重要な工程です。 確認すべきは、単にコードを書く技術力があるかどうかだけではありません。 自社の業界や目的に近い開発実績があるか、ビジネスモデルを深く理解したうえで要件定義をリードしてくれる支援力があるかを厳しくチェックしてください。 特に、ユーザーの使い勝手に直結するUI/UX設計の強さや、品質を左右するテスト・QA体制の充実度は、リリース後の不具合リスクを減らす鍵となります。 また、セキュリティ対策の信頼性やストア審査に関する深い知見、リリース後の保守・運用・継続的な改善まで伴走してくれる体制があるかどうかも見極める必要があります。 見積価格の安さだけに目を向けるのではなく、品質、将来の拡張性、そして万が一のトラブル時におけるサポート体制のバランスが取れているかを重視してください。 複数の会社を比較する際には、これら多角的な視点で質問を投げかけ、自社の事業成長を真に支えてくれるパートナーであるかを判断することが重要です。 発注者側が持つべき心構え 丸投げしない： 目的や優先順位の最終判断は自社で行う。 段階的に育てる： 最初から完璧を目指さず、リリース後の改善を前提とする。 品質を「投資」と捉える： テストやセキュリティを削らず、長期的な資産として育てる。 アプリ開発を成功させるためには、技術的な知識以上に発注者側のスタンスが重要になります。 最も避けるべきは開発会社への「丸投げ」です。 アプリの目的や機能の優先順位、最終的な判断基準は常に発注者側が保持し続けなければなりません。 また、最初からすべての機能を完璧に盛り込もうとするのではなく、まずは本質的な価値を検証するための最小構成から始め、市場の反応を見ながら段階的に育てるという柔軟な考え方を持つことが推奨されます。 さらに、リリース日をプロジェクトの終わり（ゴール）ではなく、ユーザーと共に歩む改善サイクルの始まり（スタート）と捉える意識の転換が必要です。 品質管理やテスト、セキュリティ対策、リリース後の運用保守にかかるリソースを「余計なコスト」ではなく、アプリを健全に成長させ、事業成果を最大化するための「必要な投資」として捉えてください。 こうした一歩引いた冷静な視点と、主体的な関わり方が、社内の信頼を獲得し、価値あるアプリを生み出す基盤となります。 まとめ 初めてのアプリ開発プロジェクトを成功させる鍵は、技術的な知識以上に、「なぜ作るのか」「誰がどう使うのか」という本質を突き詰める準備にあります。 今回ご紹介した12の失敗パターンは、どれも事前に知っていれば防げるものばかりです。 開発前： 目的を数値化し、MVP（最小限の機能）から始める。 開発中： UX（ユーザー体験）とテスト、セキュリティを妥協しない。 リリース前後： ストア審査や集客・運用の計画を並行して進める。 アプリ開発は、リリースした瞬間が「本当のスタート」です。 開発会社を単なる作業依頼先としてではなく、共にアプリを育てるパートナーとして選び、発注者側が明確な判断基準を持つことが、失敗のリスクを最小限に抑えます。 まずは、「本当にアプリである必要があるのか」という原点に立ち返り、社内の合意形成から始めてみましょう。 事前のチェック項目を一つずつ埋めていくことが、結果として予算と納期を守り、ユーザーに愛されるアプリへの最短距離となります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

はじめに こんにちは。入社2年目に突入したセキュリティコンサルタントの石尾です。本記事は情報セキュリティのベストプラクティスをまとめたCIS Controlsについて、セキュリティコンサルタントが学んでいくシリーズの第2回です。「CIS Controlsってなに？」という疑問をお持ちの方はぜひ前回の記事を見てみてください。第2回では脆弱性管理にフォーカスしていきます。 脆弱性とは セキュリティ界隈の方以外にはあまり聞き馴染みがないと思いますが、脆弱性（ぜいじゃくせい）と読みます。 NTTドコモビジネスによると、脆弱性とは、 コンピューターのOSやソフトウェア、ハードウェアにおい

開発・検証用にintdashサーバーを動かしたいエンジニアのみなさん、 こんにちは、ソリューションアーキテクトの伊勢です。 intdashの2025年版からDockerでサーバー環境を構成できるようになりました。 製品マニュアルページで サーバーの構築 の1パターンとして AWS EC2上のDocker（簡易環境） の構築手順を公開しています。 1 今回はその理解を助けるため、各ステップの目的・準備・結果確認を噛み砕いてintdash環境を構築し、サーバーのログや設定を確認してみます。 2 はじめに 全体の流れ サーバー構成 AWS CDK 構築手順イメージ 手順前提 ツール準備 環境構築 準備 EC2インスタンス構築 アプリ起動 起動確認 SSLサーバー証明書設置 サーバードメイン名の準備 Let's Encryptで証明書設定 メールサーバー設定 管理者ユーザー設定 Google Maps APIキー設定 計測開始 intdash Motion起動 ログ確認 確認コマンド 計測時のログ確認 WebSocket接続 計測新規作成 アップストリーム開始 基準時刻受信 データ伝送 計測停止 負荷確認 AWSコンソール top コマンド 設定 設定確認 設定変更 バックエンド：ログイン試行回数変更 フロントエンド：ロゴ変更 おわりに はじめに 全体の流れ 全体像を捉えられるようにサーバーの構成から説明します。 サーバー構成の説明 EC2上にDockerでintdashサーバーを構築 ブラウザ・Motionから接続確認 データ送信とログ確認 負荷・データ・設定の確認 サーバー構成 通常、intdashのサーバーサイドは、2種類のインスタンスで構成されます。 3 APIインスタンス Webサーバー、API、認証、データ伝送、データやメディア管理 DBインスタンス ユーザー／エッジ／計測の保存、計測の時系列データの保存 通常のインスタンス・サービス構成 簡易環境では、1つのEC2インスタンスにAPI/DB双方のサービスが同居します。 4 EC2簡易環境 AWS CDK 簡易環境の構築にはAWS CDK（AWS Cloud Development Kit）を利用します。 AWS CDKとはインフラ構成をコードで記述したもので、このコードは AWS CloudFormation のテンプレートに変換されます。 AWS CloudFormation は、インフラ構成を定義したテンプレートで自動的に構築・更新・削除するサービスです。 CDKで生成したテンプレートをもとに CloudFormation がインフラを構築・更新・削除を自動化、状態を管理します。 構築手順イメージ 構築手順は大まかに ①〜③インフラ構築 ④〜⑥アプリ構築 にわかれます。 構築手順 作業用PC AWS CDKでテンプレートを生成してCloudFormationを起動します。 AWS CloudFormation テンプレートと元にAWSリソースを構築します。 EC2インスタンス Docker Composeで各サービスのコンテナを構成・起動します。 コンテナ構成定義から環境変数を読み込みます。 手順前提 事前に以下が必要です。 作業用PC AWS CLI、およびAWS CDKを実行します。 マニュアルのコマンドはLinux準拠です。 5 AWSアカウント EC2などのリソースが構築されるAWS環境です。 AWS IAMユーザー 作成するAWSリソースに権限が付与されている必要があります。 intdashライセンス アクティベーションキー intdashサーバーを有効化するため、設定します。 intdashライセンスを契約すると発行されます。 サーバードメイン名 サーバーにFQDNでアクセスするために必要です。 今回はAWS Route53で払い出す手順を紹介します。 ツール準備 作業用PCに必要なツールがインストールされているか確認します。 AWS CLI EC2へのSSH接続時、AWS CDK実行時の認証に使います。 Node.js Node.js 本体のバージョン管理ツールです。 npm パッケージを実行ツールです。AWS CDKスクリプトを実行します。 aws --version node -v nvm --version npm --version Node.jsのバージョンが古かったので最新版をインストールしました。 AWS CLI、Node.js / npmの確認 環境構築 準備 マニュアルの通り、以下を準備します。 6 AWS CLIの認証情報 キーペア作成、AWS CDKデプロイ時の認証のために設定します。 AWS CLI認証情報 EC2インスタンス構築 ここからインフラ構築を始めます。 まず、作業用PCで実行するデプロイ資材をダウンロードします。 CDK資材ダウンロード インタラクティブモードでAWS CDKのセットアップを開始します。 セットアップ開始 今回、intdash最新バージョンにあわせてRocky Linux 9イメージを使用します。 7 rockylinux.org Version: 9.7 Region: ap-northeast-1 Architecture: x86_64 Rocky Linux9.7イメージのAMI IDをコピー 確認したRocky Linux 9イメージのAMI IDを指定してデプロイします。 また、削除時のElastic IP保持を指定しています。 Elastic IPを確認 生成されたペアキーを安全な場所に置き、 EC2インスタンスにログインできるか確認します。 mv ./intdash-trial-key.pem ~/.ssh ssh -i ~/.ssh/intdash-trial-key.pem rocky@ < Elastic IP > sudo su - intdash ログイン確認 アプリ起動 セットアップが完了すると、すでにintdashサーバーが起動しています。 起動確認 ブラウザで https://intdash.<Elastic IP>.nip.io にアクセスします。 ログイン画面 ログインしてProject Consoleが表示されることを確認します。 Project Console画面 もしアクセスできない場合はログを確認します。 # ステータス確認 sudo systemctl status intdash-trial Docker Composeの全コンテナのログを確認する方法です。 auth-1 などコンテナ名が表示されます。 # リアルタイム表示 journalctl -u intdash-trial -f # 直近100行 journalctl -u intdash-trial -n 100 # 直近10分 journalctl -u intdash-trial --since " 10 minutes ago " 全コンテナログ ログインできない場合、Authentication Serviceのログを確認します。 特定コンテナのログを表示する方法です。 Docker Composeのサービス名 auth を指定します。 cd ~/deployment/ # 直近100行 docker compose -f docker-compose.yml logs auth | less # 直近10分 docker compose -f docker-compose.yml logs auth --since 10m | less 特定コンテナログ SSLサーバー証明書設置 このままではHTTPS通信ができません。 ブラウザではアクセスできますが、今回エッジとして利用する intdash Motion でアクセスできません。 続きの手順でHTTPS通信できるようにします。 SSLサーバー証明書設置前 今回は以下のように準備しました。 サーバードメイン名 今回はAWS Route 53で取得します。 サーバードメイン名の準備 本記事用に取得しています。 AWS Route53でドメイン名を購入します。最安で$15/月です。 ドメイン購入 登録に数分かかります。 完了するとVerifyメールが届きます。クリックします。 ドメイン登録のVerifyメール EC2インスタンスのIPアドレスを割り当てるサブドメインのレコードを作成します。 サブドメインレコード作成 全世界のDNSサーバーに登録が開始され、しばらくすると名前解決できます。 8 dig < サブドメイン名 > 名前解決成功 Let's Encryptで証明書設定 EC2インスタンス上でHTTPS通信のための証明書・秘密鍵を生成します。 Let’s Encrypt の証明書発行ツール Certbot をインストールする前に、Rocky Linuxのパッケージ管理コマンド DNF（Dandified Yum） で追加パッケージリポジトリ EPEL（Extra Packages for Enterprise Linux） をインストールします。 sudo dnf install -y epel-release sudo dnf makecache EPELインストール マニュアル通り、Certbot でSSLサーバー証明書と秘密鍵を発行します。 SSLサーバー証明書・秘密鍵発行 intdashサービス起動の前に、デプロイ資材の環境変数 FQDN を取得したサブドメイン名に変更します。 FQDN変更 これで intdash Motion でHTTPSアクセスできるようになります。 intdash MotionでHTTPSアクセス メールサーバー設定 マニュアル通りにメール設定を環境変数に追加します。 元の AUTH_SMTP_ADDRESS: " mail:1025 " AUTH_SMTP_HOSTNAME: " auth " はコメントアウトします。 9 メールサーバーと通知メール送信元を設定 AUTH_SMTP_PASSWORD に設定する <Gmail用のアプリパスワード> は Googleアカウント > 2段階認証プロセス > アプリ パスワード で発行します。 アプリパスワードの発行 管理者ユーザー設定 マニュアル通り、管理者ユーザーのメールアドレスを登録します。 メールアドレス追加 確認メール メールアドレス確認済み Google Maps APIキー設定 Google Maps APIキーを準備します。 Map JavaScript APIを有効化します。 自サイトだけで利用できるようウェブサイトでアプリケーションの制限を設定しておきます。 Google Maps APIキー準備 あとはマニュアル通り、Google APIキーを設定します。 Google Maps APIキー設定前 Google Maps APIキー設定後 計測開始 intdash Motion起動 intdash Motion の計測を起動します。 アップストリームを Edge Finder 、作成された計測を Meas Hub で確認します。 Edge Finderの確認 Meas Hubの確認 ログ確認 確認コマンド 全コンテナのログは journalctl で確認できます。 journalctl -u intdash-trial -f journalctl -u intdash-trial -n 100 journalctl -u intdash-trial --since " 10 minutes ago " 各テナントのログはDocker Composeの logs コマンドで確認できます。 cd deployment/ docker compose -f docker-compose.yml logs < container > | less docker compose -f docker-compose.yml logs < container > --since 1h | less なお、本構成では特にDocker Composeのロギング設定をしていません。 10 計測時のログ確認 計測起動時のBroker Serivceコンテナのログを確認してみます。 docker compose -f docker-compose.yml logs broker -f Broker Serviceコンテナログ WebSocket接続 Motionで計測を開始すると、一度WebSocketが切断されます。 "msg":"Received Disconnect" その後、改めてWebSocketの接続ログが出力されます。 "msg":"Received WebSocket:\tua:Motion/49 CFNetwork/3860.400.51 Darwin/25.3.0 referer: remote_ip:xxx.xxx.xxx.xxx:46928 proto:HTTP/1.1" "msg":"Received ConnectRequest request_id:0 protocol_version:2.0.0" "msg":"Authenticated by OAuthToken subject:c82b7aba-b9e1-46a8-a8b4-87c7384ce140" 計測新規作成 "msg":"Received","tenant_id":0,"project_id":"00000000-0000-0000-0000-000000000000","user_id":"c82b7aba-b9e1-46a8-a8b4-87c7384ce140" "path":"/api/v1/projects/00000000-0000-0000-0000-000000000000/measurements" アップストリーム開始 "msg":"Received UpstreamOpenRequest request_id: 2 session_id: 6fd90f07-0dca-47f0-8419-776b995bc876 qos: unreliable ack_interval: 100ms expiry_interval: 1m0s persist: true" "msg":"Succeeded in opening upstream. id=[4f5442cf-74e3-4f98-9695-0f566f5a3127] qos=[unreliable]","tenant_id":0,"message_track_id":"8565-2830-1198","transport_track_id":"4629-1820-3724" 基準時刻受信 "msg":"Received UpstreamMetadata request_id: 4 metadata: *message.BaseTime" 計測開始からここまでが一気に出力されます。 データ伝送 継続中は以下が続きます。 "msg":"MessageCount rx: 0 [msg/sec] tx: 3 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" .. "msg":"MessageCount rx: 1 [msg/sec] tx: 6 [msg/sec]","tenant_id":0,"message_track_id":"6601-6588-7707","transport_track_id":"1239-5713-3538" 計測停止 Motionで計測を停止すると以下が出力されます。 "msg":"Received UpstreamCloseRequest request_id: 8 stream_id: 4f5442cf-74e3-4f98-9695-0f566f5a3127" stream_id は Succeeded in opening upstream. の id と一致しています。 負荷確認 運用でよく確認するサーバー負荷を見てみます。 Motion から以下のデータを5分間ほど送信します。 わかりやすく負荷を上げるために映像データを最大量で送信してみました。 11 映像: H.264 FullHD 30 FPS 8.2 Mbps 音声: PCM IMU GPS 瞬間的に8〜12 Mbps超 AWSコンソール AWSコンソールで推移を確認します。 AWSコンソールの確認 CPUが40%、データ受信が40 MB（≒ 5.5 Mbps）を超えています。 top コマンド top コマンドでメモリの推移を確認します。 top コマンド確認 メモリ使用は 6.5 GBを超えています。 なお、データ格納領域 /data が 98 GB ほど使われています。 df コマンド確認 設定 設定確認 秘匿情報や環境固有情報は、デプロイ資材の .env ファイルからDocker Composer設定ファイルに伝播するようになっています。 例えば、先ほど設定した FQDN は NGINX_SERVER_NAME などに伝播します。 docker-compose.yml 設定変更 では、一部の設定を変更してみましょう。 バックエンド：ログイン試行回数変更 わかりやすい例として Authentication Service の設定を変更します。 Authentication Service user-password attempt-limit : パスワード試行回数のリミット デフォルト値: 5 この回数間違えるとユーザーはロックされます。 正しいパスワードでもログインできなくなります。 ログインするにはロック解除かパスワード再発行が必要です。 Authentication Serviceの項目を持つ docker-compose.api.yml を編集します。 パスワード試行回数のリミットを1回に変更します。 サービス名、セクション名、設定項目をつなげて項目名を AUTH + _ + USER_PASSWORD + _ + ATTEMPT_LIMIT にします。 AUTH_USER_PASSWORD_ATTEMPT_LIMIT : 1 サービス auth を再起動します。 docker compose up -d auth パスワード試行回数の変更・再起動 Admin Consoleでユーザー test を作り、ログインを1度失敗します。 ログイン失敗 intdash ユーザーで test ユーザーを確認すると "ロック中" になっています。 ログイン試行1回失敗でロック中 フロントエンド：ロゴ変更 例外として、フロントエンドはWebデプロイ資材を直接書き換えます。 今回はData Visualizerのロゴを変更してみます。 標準は画面左上に出てくる VISUAL M2M の画像です。 標準ロゴ 以下の設定項目を変更します。 VM2M Data Visualizer（フロントエンド） vm2m-2nd-configの設定 header logoImgURL : Data Visualzierのヘッダロゴ AWS S3に配置・公開した 幅200px、高さ56px のPNGファイルを指定します。 PNGファイルS3配置 cd deployment/ vi docker/ui-conf/vm2m-data-viz-backend/config/vm2m-2nd-config/vm2m-2nd-config.production.json " header ": { " logoImgURL ": " https://s3.ap-northeast-1.amazonaws.com/<S3_BUCKET_NAME>/docker.png " } , vm2m-2nd-configの編集 Data Visualizerサービスを再起動してData Visualizerを表示します。 docker compose restart vm2m-data-viz-backend カスタムロゴ おわりに Dockerで開発用のintdash環境を構築してみました。 普段は意識しないサービスやDB構造を確認することで理解が深まり、 設定やログ、パフォーマンスを見ることで運用イメージがつきました。 設定項目は他にも多くあるので、また別の機会にご紹介できればと思います。 簡易環境の構築方法としては、これまでAWS マーケットプレイスにAMIを提供していました。コンテナイメージとDocker Composeでの仮想化により、AWS以外での構築方法と統合され、バージョン最新化も容易になりました。 ↩ 構築および運用手順はintdashの公式マニュアルをご参照ください。閲覧にはユーザー登録が必要です。 ↩ 冗長構成では各サービスごとにインスタンスが細分化、またスケールアウトします。 ↩ 簡易環境は開発用途の構成であり、本格的な運用には向きません。本番環境向けの構成は Kubernetes または RPM で構築します。 ↩ WindowsではWSLのUbuntu環境などで実行できます。 ↩ 本記事では、基本的に公式マニュアルに沿って進め、各ステップで「どういう目的で何が行われているか」「構築結果をどう確認するか」にフォーカスして解説します。 ↩ 利用するAMI IDはリージョンなどにより異なるため、Rocky Linux公式サイトで最新のものを確認してください。 ↩ ICMPポートは開けていないため、pingは通りません。 ↩ デフォルトではコンテナ内のSMTP（mailコンテナ）を使用していますが、外部SMTP（Gmail等）を利用するように変更します。 ↩ ログはDockerコンテナが再作成されると消えてしまいます。必要に応じて Docker Compose の設定で syslog 等で外部保存します。 ↩ なお、Motion側のWi-Fi帯域を超えており、データ量の86.4 %しか送信できていません。 ↩