はじめに
社内でAIを活用した開発について考える機会があり、これまでの記事では、AIエージェントの考え方や、Claude Codeの概念・設計について整理してきました。
生成AIを活用することで、ある程度のアプリケーションは短時間で作れるようになり、「どう作るか」というハードルは大きく下がってきていると感じています。
一方で、実際に価値を出すためには、作ったものを「どのように届けるか」という視点が重要になると感じました。
本記事では、サービスのリリース形態と、それを支える技術の変化を踏まえながら、エンジニアとしての価値について整理してみました。
サービスのリリースと選択の重要性
今回の内容で特に印象的だったのは、リリース方法の多さと、それを知っているかどうかで提案の質が大きく変わるという点です。
単に「アプリを作る」のではなく、お客様の利用環境や目的に応じて、最適なリリース手段を選択する必要があります。
例えば、
- 社内マニュアル → Web / Notion
- 業務効率化 → Chrome拡張 / Slack Bot
- 外部連携 → API / GAS
といったように、「やりたいこと」から逆算してリリース方法を決めることが重要です。
また、
「スタート（課題）とゴール（リリース形態）が分かればお客様と話ができる」
という考え方も刺さりました。
選択肢を知らないと、本来シンプルに解決できる問題でも遠回りしてしまいます。引き出しを持つこと自体がエンジニアとしての価値になると感じました。
リリースを支える技術の変化
リリース手段を理解した上で重要になるのが、それをどのように実現するかという点です。
従来は、アプリケーションを公開するために、インフラ構築や環境整備に多くの時間と専門知識が必要でした。
■ インフラという壁
従来の開発では、
- サーバー構築（Linux / Nginx など）
- ネットワーク設定（DNS / SSL）
- データベース構築
- セキュリティ対応
といった工程が必要であり、リリースまでに大きな時間がかかっていました。
■ インフラ構築の変化（IaC・コンテナ）
現在は、
- Infrastructure as Code（IaC）
- Dockerなどのコンテナ技術
により、インフラ構築や実行環境の扱い方が大きく変化しています。
IaCでは、インフラ構成をコードとして管理できるようになり、Terraformのようなツールを使うことで、コードを書いて実行するだけで環境構築が可能となっています。これにより、従来1ヶ月かかっていた作業が短時間で完了するようになっています。
コンテナ技術については、アプリケーションの実行環境を統一できるため、開発環境と本番環境の差異が少なくなり、より安定したリリースが可能になっています。
これらの技術により、インフラ構築は専門領域というよりも、開発の一部として扱えるようになってきています。
■ BaaSという選択肢
インフラやバックエンド構築の負担を大きく下げる手段として、BaaS（Backend as a Service）の存在も学びになりました。
BaaSを利用することで、認証・データベース・ストレージ・APIといったバックエンド機能をクラウドサービスとして利用でき、開発者はフロントエンドやロジックに集中できるようになります。
代表的なサービスとしては、
- Firebase（リアルタイム機能や認証が統合）
- Supabase（PostgreSQLベースでRDB設計に強い）
- AWS Amplify（AWSと統合したフルスタック構成）
などがあり、用途に応じて選択できます。バックエンド構築のハードルも確実に下がっています。
■ フロントエンド中心の構成とホスティング
データの永続化を伴わないシンプルなアプリケーションや、APIを活用した軽量な構成であれば、ホスティングサービスを使うことで手軽に公開できます。
代表的な例として、Vercel が挙げられます。VercelはNext.jsの開発元が提供するデプロイ・ホスティングサービスで、以下のような特徴があります。
- GitHubと連携した自動デプロイ
- プレビュー環境の自動生成
- エッジネットワークによる高速配信
静的サイトから、サーバーサイド処理（API RoutesやEdge Functions）を含む構成まで幅広く対応しており、個人開発でも扱いやすいサービスです。
■ 軽量な自動化・API（GAS）
さらに軽量な選択肢として、Google Apps Script（GAS）も印象的でした。
GASを利用することで、以下のような処理を比較的簡単に実装することができます。
- スプレッドシートのデータ操作
- 定期実行（トリガー）
- 簡易的なAPIの作成
- Gmail / カレンダー / Driveとの連携
- Slack / Notionなど外部サービスとの連携
フルスタックな構成を組まなくても、目的によってはこういった軽量な手段で十分に価値を提供できます。
■ 実例：短期間でのサービス構築
実際の例として、案件メールと人材マッチングを自動化するサービスが紹介されていました。
- メールを自動取得
- データ化
- AIでマッチング
といった機能を持つアプリケーションが、GCPでのドメイン取得・ステージング環境・本番環境の構築を含むゼロイチ開発が約4日で完成 したとのことでした。
従来であれば複数人・数ヶ月かかるような開発が、設計とAIの活用によって短期間で実現できるようになっている点は、素直にすごいと思いました。
エンジニアの役割の変化
このような変化の中で求められるのは、単なる実装力ではなく「設計力」だと感じます。
AIを活用する上での役割は、段階的に広がってきています。
| フェーズ | 概要 |
|---|---|
| プロンプトエンジニア | いかに適切な指示を書くかを重視する |
| コンテキストエンジニアリング | やり取りの流れや文脈全体を設計する |
| ハーネスエンジニアリング ※ | タスクを分解し、AIや外部システムを組み合わせて実行の流れを設計する |
※「ハーネスエンジニアリング」は比較的新しい言葉で、
まだ明確に定義が固まっていない印象があります。
本記事では、「AIや外部システムを含めた全体の処理フローを設計する」という意味で使用しています。
今後は、AIを単体で使うのではなく、全体の流れを設計できる力が問われてくるのではないかと思っています。
まとめ
AIの進化により「作ること」のハードルは大きく下がりました。その中で重要になるのは、どこにリリースするか・どのように構築するか・どの手段を選択するかといった設計の部分であり、エンジニアの価値はそこにシフトしていると感じました。
記事としてまとめてはいますが、自分自身の課題も改めて明確になりました。
これまで実装ばかりで、環境面には疎い部分が多くありました。Dockerすら使いこなせていない状態なので、まずはそこから始めたいと思っています。
具体的には、
- Dockerを触ってコンテナ技術を理解する
- 最低限のインフラ知識を身につける（GCPなどのクラウドで自分でゼロイチ構築を経験する）
- リリース手段を広げる（Vercel / GAS / BaaSなど、選択肢を実際に使って覚える）
- 提案を意識してサービスを使う（お客様の課題から逆算して、何が最適かを考える習慣をつける）
「作れる」だけでなく、「どこに・どうやって届けるか」まで提案できるエンジニアを目指していきたいと思います。
引き出しを増やしながら、実際に手を動かして経験を積んでいきたいと思います。