ソースコードを書かなくなったエンジニア――AIとCI/CDで変わった開発スタイル

Writer：maekawa　更新日：2026/08/12

デジナーレ大阪オフィスの前川です。

最近はソースコードを書くことがほとんどなくなりました。開発をしなくなったわけではありません。むしろ以前より多くの改善を、短いサイクルで届けられるようになっています。

現在は、CodexやClaude CodeのようなAIエージェントへ指示を出し、その成果を確認することが作業の中心です。

少し前までは、AIが変更したソースコード差分を目視で確認しコミットしていました。しかし、ここ半年ほどで、実装から検証までを一つのタスクとしてAIに任せたほうが、開発の速度と品質が安定する場面が増えました。追加の観点を後から伝えても、既存機能を壊すケースは少なくなっています。

外出中や会議の隙間時間にスマートフォンから修正を依頼し、手が空いたときに結果を確認します。問題がなければ、変更は定められた承認とCI/CDを通ってステージング環境や本番環境へ反映されます。案件の性質にもよりますが、そのような開発が現実になっています。

---

開発を支える3つの仕組み

現在の開発は、次の3つの仕組みを組み合わせて成り立っています。

Codex/Claude Codeで開発を進める

CodexやClaude CodeをGitHubのリポジトリと連携させることで、プロジェクトファイルを修正しテストやビルドを実行します。エラーが出れば原因を調査し、修正したうえでPRを作成するところまで進められます。

また、クラウド実行を利用すればGitHubと接続した隔離環境でタスクをバックグラウンド実行できます。こうした手元の端末やPC性能に依存せず、複数の開発を並行して進められます。

GitHub/GitHub Actionsで変更と品質を管理する

変更されたソースコードはGitHubで管理します。PR上で差分や変更履歴を確認でき、必要に応じてレビューを行えます。

AIが作ったコードを実際の環境にデプロイする前に置く品質ゲートがGitHub Actionsです。

GitHub Actionsでは、PRの作成やブランチへのマージを契機に、テスト、ビルド、デプロイなどを自動実行できます。

一方で、すべての変更に同じ重い検証を課すと、軽微な修正にも時間がかかります。変更の影響範囲やリスクに応じて、どこまで品質ゲートを通すのかを設計する。このあたりには、エンジニアの経験やチームのノウハウが生きてきます。

AWSで公開と運用を支える

ブランチへマージされた変更がGitHub ActionsをトリガーにAWSへデプロイされます。

また、AWSはアプリケーションの実行環境だけではなく、ログの収集、監視、アラート通知など、運用基盤にもなります。

インフラ構成もSAMやCDKなどでコードとして管理しておけば、AIはアプリケーションとインフラの両方を確認しながら変更できます。

GitHub ActionsからAWSへ接続する際は、長期間有効なアクセスキーではなく、OpenID Connect（OIDC）を利用して、実行時に短時間だけ有効な権限を取得できます。

---

スケジュール実行で、指示する作業も減らせる

クラウド上で完結する処理であれば、手元のPCを起動せずに定期実行できます。この領域は、アイデア次第でもっと活用方法を広げられると考えています。

たとえば「毎朝、前日に失敗したテストを調査して報告する」「毎週、依存関係とドキュメントの差分を確認する」といった作業なら、人間が毎回指示しなくても継続的に実行できます。

実装方法以外の要件を伝えるのが重要

このような開発スタイルになってもこれまでの開発経験が不要になるわけではありません。むしろ、その経験をAIに伝え、盛り込むことが重要になります。

そこで伝えているのが、ビジネスや業務を理解し、セキュリティ、運用、コスト、法務、分析まで考慮してシステムを作るための判断基準です。長年の開発経験で培った知見をAIへ渡すことで、単に動くだけではなく、業務で継続して使えるシステムを目指しています。

システムの性質にもよりますが、次の観点をAIへの指示、プロジェクトルール、設計、実装、インフラ、運用手順へ反映しています。

観点	AIとチームに共有する内容
ビジネス・業務	目的、対象利用者、業務フロー、ロール、承認や例外処理
品質・利用者体験	操作性、スマートフォン対応、性能、アクセシビリティ
セキュリティ・法務	権限、秘密情報、個人情報、利用規約、著作権、ライセンス
運用・障害対応	ログ、監視、アラート初動、影響調査、通知、ロールバック
コスト・保守	構成の複雑化を避ける、不要なリソースを持たない、テストや資料を残す
分析・改善	KPI、イベント、利用者やセッションの定義、SEO、改善効果の検証
組織・企業文化	品質基準、意思決定の考え方、AIに任せる範囲、失敗の共有と再発防止

これらは、その場限りのプロンプトではなく、プロジェクトルール、Skill、設計資料、テスト、GitHub Actions、監視手順へ移しています。経験を会話の中だけに残さず、チームとAIの両方が繰り返し使える資産にするためです。

---