AIがコードを書くなら、人は何を決めるのか。GitHub公式のCI・レビュー機能から3つに整理する

📌 あわせて読みたい: AIが書いたコードを受け取った直後の確認点はAIに実装を任せた後、「動いた」以外に確認する4つのことへ。この記事はその一段上、開発の工程のうち、どこを人が決めているのかを地図にする話です(個別の確認手順ではなく、工程の分け方を扱います)。

この記事では、GitHubが公式に説明しているCI・テスト・レビューの機能を土台にして、開発の工程を分け、そのうち人が決めている場所だけを取り出します。

結論:人が決めているのは「要件」「期待値」「判断」の3つ

• 要件を決める — 何を作るのか、どこまでできていれば完了なのかを言葉にする
• 期待値を決める — テストで「何が正しい結果か」を先に決める
• 差分とレビュー結果を判断する — 変更内容と自動チェックの結果を読み、承認・変更要求・マージを決める

この3分類は、GitHubの公式機能を学習の対象へ対応させた本記事の編集上の整理です。職業の将来や、どのスキルなら収入・採用につながるかを予測するものではありません。以下、公式ドキュメントの記述と対応させながら見ていきます。

まず、自動で回っている部分を確認する

GitHubは、継続的インテグレーション(CI)を、共有リポジトリへ頻繁にコードをコミットすることを求めるソフトウェアの実践として説明しています。そしてCIのテストには、コードのスタイルを確認するリンター、セキュリティチェック、コードカバレッジ、機能テスト、その他のカスタムチェックを含められる、としています。

さらにGitHubは、GitHub ActionsのCIワークフローがリポジトリをビルドしてテストを実行し、各テストの結果をプルリクエスト上で提供すると案内しています。つまり「動かして結果を出す」ところは、設定さえ置けば自動で回ります。人が毎回手を動かす場所ではありません。

ここまでを引いた残りが、この記事で扱う3つです。

1つめ:要件を決める

何を作るのか、どこまでできていれば完了とみなすのかを言葉にすることは、この記事が「人が決める」とした3つのうちの1つ目です。

これはAIにコードを書かせる場合も同じで、要件を言葉にするのは人の仕事です。

2つめ:期待値を決める

テストは「実行される」ものですが、何を正しい結果とみなすかは、テストを書く時点で人が決めています。リンター、セキュリティチェック、カバレッジ、機能テストのどれを置くかという選択も同じです。

GitHubの説明にあるとおり、CIに含められるチェックには幅があります。どれを自分のプロジェクトに置くかは、CIの機能そのものではなく、決める側の判断です。テストの意味そのものについてはテストは何のために書くのかで扱っています。

3つめ:差分とレビュー結果を判断する

プルリクエストのレビューでGitHubが挙げている操作は、次のとおりです。

• プルリクエスト全体に対する一般的なフィードバックを残す
• 特定の行にコメントして、質問したり懸念を説明したりする
• 変更を提案する

そしてレビューを終えるときには、ApproveまたはRequest changesを選べると説明されています。

差分を読むときにGitHubが例として挙げているのは、バグ、ロジックの誤り、不足している例外処理、アクセシビリティ上の問題、将来このコードを読む人にとって不明瞭な点の確認です。またGitHubは、AIによるレビュー提案について、どの変更が機能を改善するかは利用者が判断すると案内しています。提案が出ること自体と、それを取り込むかどうかは別です。

3つを、学習の棚卸しに使う

繰り返しになりますが、この対応表は公式機能を工程へ並べ直した整理であり、将来どの職種が残るかを示すものではありません。

🔗 次に読む

• 変更履歴と置き場所の前提から確認したい方はGitとGitHubは何が違う?へ。
• 仕事全体でAIをどう組み込むかは生成AIの業務活用 完全ガイド(2026年版)へ。
• (公開後に追加)テストをGitHub Actionsで動かすCIの入口

※本記事は2026年7月24日に確認したGitHub公式ドキュメント(継続的インテグレーション、プルリクエストのレビュー、変更内容の確認)の説明に基づく整理です。テストやレビューを行うことで不具合や要件の漏れがなくなることを示すものではありません。