アプリ開発におけるArtifact：定義、種類、管理方法

開発におけるArtifactとは

アーティファクト（ビルドアーティファクト）とは、ソースコードのコンパイル結果であり、デプロイや依存関係としての使用が可能です。ビルドプロセスは、ソースファイル（Java、Kotlin、Swift、C++など）を、ターゲットデバイスやサーバーで実行可能なバイナリパッケージに変換します。

アーティファクトの概念は実行可能ファイルにとどまりません。例えば、JARライブラリは他のプロジェクトで依存関係として使用されるアーティファクトです。Dockerイメージはアプリケーションとその環境を含むアーティファクトです。テストカバレッジレポートでさえ、CI/CDの文脈ではアーティファクトと見なせます。

大企業における現代の開発では、数十万ものアーティファクトの管理が伴います。Google DORAは、アーティファクト管理の成熟度をDevOps全体の効果と関連づけており、アーティファクトレジストリを使用するチームはリリースが速く、デプロイの問題が少ないことが示されています。

アーティファクトのライフサイクル

各アーティファクトは複数の段階を経ます：作成（ビルド、コンパイル）、検証（テスト、セキュリティチェック）、保存（アーティファクトレジストリ）、配布（ダウンロード用公開）、アーカイブまたは削除（バージョンが古くなった場合）。

モバイル開発におけるアーティファクトの種類

プラットフォームや技術によって、生成されるアーティファクトの形式は異なります。形式を理解することは、CI/CDパイプラインを正しく設定し、ストレージシステムを選択するために不可欠です。

Androidアーティファクト

APK（Android Package Kit）は従来のインストールパッケージ形式です。AAB（Android App Bundle）はGoogle Playで公開するための最新フォーマットで、特定のデバイスに必要なリソースのみを含みます。AABはユニバーサルAPKと比較して、インストールされるアプリケーションのサイズを平均15〜20％削減します。

iOSアーティファクト

IPA（iOS App Store Package）は、iOSデバイス用のコードとリソースを含むアーカイブです。XCArchiveはXcodeによって作成される中間アーティファクトであり、そこから最終的なIPAがエクスポートされます。dSYMは、クラッシュログのシンボル化に必要なデバッグシンボルファイルです。

サーバーおよびライブラリプロジェクトのアーティファクト

JAR（Java ARchive） — Java/Kotlinライブラリ用。AAR（Android ARchive） — リソースを含むAndroidライブラリ用。Dockerイメージ — マイクロサービスのコンテナアーティファクト。各タイプには独自のレジストリとバージョン管理ルールがあります。

CI/CDパイプラインにおけるアーティファクト

アーティファクトはパイプラインの各ステージをつなぐ役割を果たします。各ステージは前のステージのアーティファクトを消費し、新しいものを生成します。このフローを理解することは、効果的なCI/CDパイプラインを設定する上で極めて重要です。

パイプラインにおけるアーティファクトの流れ

典型的なフローは次のとおりです：コミット→ビルドサーバーがコードをコンパイルし、最適化されていないアーティファクトを作成→テストアーティファクトを使用してテストを実行→成功するとリリースアーティファクトが作成→署名されてアーティファクトレジストリに公開→レジストリからステージング環境と本番環境にデプロイするためにアーティファクトを取得。各ステージ間の移行は、整合性チェックと要件準拠の検証を伴います。

中間アーティファクトと最終アーティファクト

パイプラインは異なるステージで複数のアーティファクトを作成できます。デバッグアーティファクトにはデバッグ情報が含まれ、最適化されていないものはテスト用に迅速にビルドされ、リリースアーティファクトは最適化と難読化が施された最終版です。CIシステムはこれらを区別し、各タイプに適切な保持ポリシーを適用できなければなりません。

name: Artifact Flow
on: [push]

jobs:
  build-debug:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleDebug
      - uses: actions/upload-artifact@v4
        with:
          name: debug-apk
          path: app/build/outputs/apk/debug/app-debug.apk
          retention-days: 7

  test:
    needs: build-debug
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: debug-apk
      - run: ./gradlew testDebugUnitTest

  build-release:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk
          retention-days: 90

キャッシュ vs アーティファクト

依存関係キャッシュとビルドアーティファクトを区別することが重要です。キャッシュ（Gradleキャッシュ、CocoaPodsキャッシュ）は繰り返しのビルドを高速化しますが、デプロイを目的としていません。アーティファクトは配布可能な最終製品です。キャッシュには数日、アーティファクトには数週間または数ヶ月のTTLを設定します。

アーティファクトリポジトリ

アーティファクトはビルドサーバーに保存すべきではありません。この目的には専門のシステムが存在します。リポジトリマネージャは、集中ストレージ、インデックス作成、アクセス制御、CI/CDツールとの統合を提供します。

人気のアーティファクトレジストリ

JFrog Artifactory — Maven、Gradle、Docker、NuGet、npm、APT、YUMをサポートするユニバーサルマネージャ。Sonatype Nexus — 主要フォーマットをサポートするオープンソースの代替手段。GitHub Packages — GitHubに組み込まれたレジストリで、既にGitHubを使用しているチームに便利。GitLab Container Registry — Dockerイメージ用。

レジストリ選択の基準

主要な要素：サポートされている形式、ライセンスモデル（オープンソース/エンタープライズ）、既存のCI/CDとの統合、リージョン間のレプリケーション機能、古いバージョンの自動クリーンアップポリシーの有無、コンプライアンスレポート。

// Jenkins pipeline — ArtifactoryへのAPK公開
def server = Artifactory.newServer(
    url: 'https://artifactory.company.com',
    credentialsId: 'artifactory-api-key'
)

def uploadSpec = """
{
  "files": [
    {
      "pattern": "app/build/outputs/apk/release/*.apk",
      "target": "mobile-apps/android/release/""
    }
  ]
}
"""
server.upload(uploadSpec)

バージョン管理と命名

適切なアーティファクトのバージョン管理戦略は、ビルドの再現性と変更追跡にとって極めて重要です。バージョン管理がなければ、本番環境で問題を引き起こしたコードのバージョンを特定することは不可能です。

セマンティックバージョニング（SemVer）

MAJOR.MINOR.PATCH標準：MAJORは互換性のないAPI変更、MINORは後方互換性のある機能追加、PATCHは後方互換性のあるバグ修正で変更されます。CI/CDでは、バージョンにビルドメタデータが追加されます：2.4.1+build.20260703.1。これにより、特定のアーティファクトを生成したコミットとその作成日時を正確に特定できます。

トレーサビリティ — Git連携

各アーティファクトは、その起源に関するメタデータ（コミットSHA、CIビルド番号、ブランチ名、ビルド日付）を含む必要があります。この情報はアーティファクトマニフェストに記録され、いつでもその作成コンテキストを再構築できます。トレーサビリティがないと、アーティファクトの管理はバージョンの推測作業となり、監査要件のある本番システムでは許容できません。

アーティファクトの命名

命名規則：{project}-{module}-{version}.{ext}。例：messaging-sdk-2.4.1.aarやapp-release-2.4.1.apk。ビルドサーバーは、GitタグやCIシステムのビルド番号に基づいて自動的にバージョンを生成できます。

• Gitタグをバージョンソースとして使用 — アーティファクトを特定のコード状態に結び付けます
• コミットSHAをメタデータに追加 — デバッグ時の正確な識別が可能に
• 保持ポリシーを設定 — 最新のNバージョンを保持し、残りはアーカイブ

スナップショット vs リリース

Maven/Gradleアーティファクトレジストリでは、リリースバージョン（固定、不変）とスナップショットバージョン（現在開発中、上書き可能）が区別されます。CI/CDパイプラインでは、スナップショットアーティファクトは開発に便利ですが、本番環境ではリリースバージョンのみを使用すべきです。

アーティファクトのセキュリティ

アーティファクトはソフトウェアサプライチェーンの重要な要素です。アーティファクトの侵害は、悪意のあるコードが本番環境に侵入する原因となる可能性があります。アーティファクトのセキュリティには複数の保護レベルがあります。

アーティファクトの署名

APKファイルはjarsignerまたはapksignerで署名され、IPAファイルはApple証明書で署名され、DockerイメージはDockerのContent Trust（Notary）で署名されます。署名は整合性を保証し、アーティファクトの作成者を確認します。CI/CDパイプラインには、すべてのサードパーティ依存関係の署名検証を含める必要があります。

脆弱性スキャン

公開前に、アーティファクトは自動スキャナー（Snyk、Trivy、Sonatype Nexus IQ、GitHub Dependabot）によってチェックされます。これらは、含まれる依存関係、使用されているライブラリのバージョン、既知のCVE脆弱性を分析します。深刻な脆弱性が検出された場合、開発者によって修正されるまでリリースは即座にブロックされます。

サプライチェーンレベル

SLSA（Supply chain Levels for Software Artifacts）は、SLSA 1（基本）からSLSA 4（最大）までの信頼レベルを定義するセキュリティフレームワークです。ビルドサーバーは、アーティファクトがどのように、どのコードからビルドされたかに関する暗号署名付きの証明書（provenance attestation）を生成する必要があります。