プルリクエストに「ローカルで確認済みです」というコメントと、スクリーンショットが3枚。レビュアーはその3枚を信じるか、自分の手元で同じ環境を作り直して確認するかの二択になります。多くの場合、前者が選ばれます。 そして数か月後に不具合が出たとき、「あのとき何を確認したのか」を復元できる材料は残っていません。
受託開発では、この構図がもう一段厄介になります。確認の証跡が、そのまま検収の材料になるからです。 顧客に「動作確認しました」と伝えるとき、根拠がチャットに貼られた画像だけだと、後から指摘を受けたときに何も示せません。
成果物を「開ける形」で置けるようになった
GitHub Actions には、ワークフローで生成したファイルを保存する Artifact の仕組みがあります。従来これは常に zip に固められていました。1つのファイルを見たいだけでもダウンロードして展開する必要があり、結果として誰も開かない置き場になりがちでした。
2026年2月26日から、zip 化しない保存に対応しています。actions/upload-artifact の v7 で archive: false を指定すると、ファイルはそのままの形で保存され、ブラウザが表示できる形式であればダウンロードせずにその場で開けます。
- name: 動作確認レポートを添付
uses: actions/upload-artifact@v7
with:
path: reports/verification.html
archive: false置いて効くのは、次のようなものです。
- テスト結果やカバレッジのレポート（HTML で出力されるもの）
- Lighthouse など計測ツールの出力
- 画面の差分を並べた比較ページ
- 移行スクリプトが出した件数・差分のサマリ
共通しているのは、「文章で説明すると長く、画像だと足りない」情報です。この層が、これまではどこにも置き場がありませんでした。
制約を先に知っておく
便利な一方で、使い方を間違えると期待どおりに動きません。導入前に把握しておくべき点があります。
archive: false は単一ファイルのみが対象です。 複数ファイルをまとめて非 zip で置くことはできません。また、この指定をすると name パラメータは無視され、ファイル名がそのまま成果物の名前になります。
この制約から、実務的な作り方が決まります。CSS や JavaScript を外部ファイルに分けたレポートは、そのままでは崩れます。 リンク先のファイルが一緒に置かれていないためです。レポート生成ツールに単一ファイル出力のオプションがあればそれを使い、無ければスタイルを埋め込んだ HTML を出力する形にします。テスト系のツールは単一ファイル出力に対応しているものが多く、ここは大きな障害になりません。
もう1つ、成果物には保持期間があり、リポジトリを見られる権限がなければアクセスできません。 顧客がリポジトリの参照権限を持っていない受託案件では、そのままではリンクを渡せません。この場合は、レポートを納品物として別途保存するか、納品ドキュメントとして何を残すかの取り決めの中に位置づけておく必要があります。
受託で効くのは「往復が減る」こと
社内開発では、この仕組みはレビューの効率化です。受託開発では、もう少し直接的に効きます。
顧客からの指摘に対して「修正しました」とだけ返すと、顧客側は自分で環境を開いて確認するところから始まります。 ここで確認結果のレポートが一緒に付いていれば、確認の起点が変わります。何を直し、何を確かめたのかが、開いた瞬間に分かるからです。
特に効くのが、次の3つの場面です。
- データ移行の検証 — 移行前後の件数、変換できなかったレコードの一覧。口頭で「問題ありません」と言うより、数字が並んだ表が1枚あるほうが早い
- 表示崩れの修正 — 修正前後を並べたページを出す。「直りました」の証明が視覚的に終わる
- 速度改善の報告 — 計測レポートをそのまま置く。数値の出どころが明確になる
これらは、検収の場で必ず聞かれることでもあります。 受け入れテストで発注側が確認する項目を、開発中から自動で出しておく形になるので、検収のための追加作業も減ります。
レポートに載せてはいけないもの
置き場ができると、次に起きるのは載せすぎです。検証レポートには、本番データがそのまま出ることがあります。
移行検証で「変換できなかったレコード一覧」を出力すれば、そこには顧客名やメールアドレスが並びます。エラーログをそのまま添付すれば、接続文字列やトークンが混ざることもあります。成果物はリポジトリの権限を持つ人が見られるため、開発メンバー以外に業務委託や短期の協力会社が入っている体制では、実質的な閲覧範囲は想定より広くなります。
対処は難しくありません。件数と種別だけを出し、実データは伏せる。個別の値が必要なら、識別子だけを載せて本文は出さない。「レポートは共有される前提で作る」と決めておけば、出力設計の段階で自然に落とせます。
自動で出るようにしないと続かない
導入して失敗するパターンははっきりしています。「余裕があるときに手動でレポートを添付する」運用にすることです。 忙しい時期に真っ先に省略され、そして忙しい時期の変更ほど後で問題になります。
ワークフローの中で常に生成し、常に添付する。生成に失敗したらそこで気づける。この形にしておかないと、証跡としては当てになりません。
逆に言えば、自動化さえしてしまえば、これは追加の手間がゼロの施策です。 CI はもともと動いているので、出力先を1つ増やすだけで済みます。
次にやること
いま動いているプロジェクトのプルリクエストを何本か開き、「確認しました」という言葉だけで済んでいるものがどれだけあるかを数えてください。 半分を超えるようなら、証跡は実質残っていません。
そのうえで、すでに CI で生成されているのに誰も見ていないレポートを探してください。 テスト結果もカバレッジも、多くのプロジェクトでは生成だけされて捨てられています。置き場を変えるだけで、見られるものになります。
CI の整備、受託案件での検証証跡の設計、検収に耐える納品ドキュメントの組み立てについては、グリームハブの開発・AI・自動化のご相談で承っています。既存のワークフロー構成によって手の入れどころが変わるため、個別にご相談ください。お問い合わせからどうぞ。
