マニフェストとは｜manifest.jsonやKubernetesなど4形式を実測

この記事で実際に動かしたもの：127.0.0.1 の 22500 番に置いた自作のページと manifest.json を Chromium 153（Chrome for Testing）に読ませ、開発者ツールと同じ仕組み（Chrome DevTools Protocol）で読み取り結果とインストール条件のエラーを記録しました。あわせて、自作のブラウザ拡張機能を6通りのマニフェストで読み込ませたときのエラー、Kubernetes のマニフェスト8通りを kubernetes-validate で検証した結果、jar のマニフェストの有無と改行1つで起動が変わる様子を確かめています。

開発の場面だけでも、開発者ツールの「Manifest」、Kubernetes の「マニフェストを apply する」、Java の「no main manifest attribute」と、指すものはそれぞれ違います。まず、どのマニフェストにも共通する形を図で示します。

flowchart TD
    A[マニフェスト<br>中身と扱い方の宣言] --> B[読む側<br>ブラウザ・K8s・JVM]
    B --> C[書いたとおりに動かす]
    B --> D[知らない項目は無視<br>壊れたら全体が無効]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（カーネル 6.18、2 CPU）。Web アプリのマニフェストは、Python 3.13.18 の http.server を 127.0.0.1:22500 で起動して配り（.webmanifest は application/manifest+json で返す設定）、Chromium 153.0.8010.12（Chrome for Testing）を playwright 1.63.0 から新しいヘッドレスモード・作業用のプロファイルで開いて、Chrome DevTools Protocol の Page.getAppManifest と Page.getInstallabilityErrors の結果を記録しました。拡張機能は同じ Chromium に --load-extension で読み込ませ、外部への通信を止めて読み込みエラーを記録しました。Kubernetes のマニフェストは、作業用の venv に入れた kubernetes-validate 1.37.0（Kubernetes 1.25〜1.37 の JSON Schema を同梱）と PyYAML 6.0.3 で検証しました。kubectl の取得は配布元への接続がこの環境の設定で拒否されたため行わず、kubectl とクラスター側の挙動は Kubernetes 公式ドキュメントで確かめた範囲だけを書いています。jar は OpenJDK 21.0.12 の javac・jar・java で作って動かしました。Android とコンテナイメージは公式の説明の範囲です。外部のサービスには接続していません。図は mermaid-cli 11.16.0 で描画を確かめています（確認日 2026年10月29日）。

マニフェストとは（ふだんの意味とITの意味）

この節では、マニフェストという言葉のもとの意味と、IT で使われるときに何を指すのかが分かります。

マニフェスト（manifest）は、英語で「積荷目録」、つまり船や飛行機に何がどれだけ積まれているかを書いた一覧のことです。形容詞としては「はっきり示された」という意味があり、「中身を明らかにする書類」という感覚が、IT での使い方にもそのまま受け継がれています。

IT のマニフェストは、プログラムやデータの「積荷目録」です。アプリの名前・版・アイコン・使う権限・起動する場所・作ってほしいサーバーの数などを1つのファイルに書いておき、ブラウザ・OS・Kubernetes・Java の実行環境（JVM）といった「読む側」がそれを読んで、そのとおりに扱います。中身そのもの（プログラム本体）とは別に、中身についての説明を書いたファイルだと考えると、どの分野のマニフェストにも当てはまります。

政治の「マニフェスト」は英語では manifesto（宣言書）にあたる言葉で、開発の話とは関係がありません。廃棄物の「マニフェスト」も同じカタカナですが、法律に基づく伝票の制度です。この記事は、ここから先を IT のマニフェストに絞って進めます。

マニフェストの種類（manifest.json・Kubernetes・jarほかの対応表）

この節では、IT のマニフェストの主な種類を、ファイル名・書式・必須の項目で並べて比べられます。

同じ「マニフェスト」でも、ファイル名も書式も読む側もまったく違います。特に manifest.json という同じファイル名が、Web アプリと拡張機能の2つの別物に使われている点が混乱のもとです。中身の項目が違うため、片方の書き方をもう片方に持ち込むと読み込まれません。

このほか、Rust の Cargo.toml は公式ドキュメントで「マニフェスト」と呼ばれ、npm の package.json もパッケージの説明を書く同じ役割のファイルです。コンテナイメージにも、どのレイヤーと設定から成り立つかを書いた JSON のマニフェストがあります（後の節で触れます）。

Webアプリのmanifest.jsonとは（PWAの入口）

この節では、Web アプリマニフェスト（manifest.json）が何のためのファイルで、ページとどうつながっているかが分かります。

Web アプリマニフェストは、Web サイトを「インストールできるアプリ」として扱うために、名前・アイコン・起動する URL・表示のしかたをブラウザに伝える JSON ファイルです。W3C の仕様名は「Web Application Manifest」で、2026年10月29日時点では作業草案（Working Draft）の段階です。PWA（プログレッシブ Web アプリ）を作るときに最初に用意するファイルの1つで、インストールしたときのホーム画面のアイコン名や、起動したときにアドレスバーを出さない表示（standalone）などを決めます。

ページからマニフェストへのつながりは、HTML の head に書く1行だけです。

<link rel="manifest" href="/manifest.webmanifest">

ファイル名は自由です。仕様が登録している拡張子は .webmanifest、推奨のメディアタイプは application/manifest+json ですが、仕様と MDN はどちらも .json などほかの拡張子も使えるとしています。そのため、create-react-app などが作る manifest.json も、仕様どおりの manifest.webmanifest も同じように働きます。手元の実測でも、拡張子を .txt にして Content-Type: text/plain で配ったマニフェストを、Chromium 153 はエラーなしで読み込みました（配信の設定は仕様どおりにしておくのが無難です）。

オフラインで動かす仕組み（Service Worker）やキャッシュの戦略は、マニフェストとは別のファイルの役目です。PWA を一通り作る手順は、関連記事「PWAの作り方｜Service Worker最小コードとキャッシュ戦略一覧」で扱っています。この記事では、マニフェストそのものの読まれ方に絞ります。

manifest.jsonの項目一覧と書き方

この節では、Web アプリの manifest.json の主な項目と、最小限の書き方の見本が分かります。

手元で Chromium に読ませた、インストール条件をすべて満たす見本です。アイコンは 192×192 と 512×512 の PNG を用意しました。

{
  "name": "RJC メモ帳",
  "short_name": "メモ帳",
  "id": "/",
  "start_url": "/",
  "scope": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#e88e2c",
  "icons": [
    { "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

相対パスの "/" は、Chromium の中では http://127.0.0.1:22500/ のような完全な URL に直され、色も #e88e2c が rgba(232,142,44,1) に変換されていました。MDN の一覧には、このほか description・shortcuts・screenshots・share_target・file_handlers・protocol_handlers・orientation・categories など24の項目が載っています。仕様上はどれも任意で、使いたい機能に合わせて足していきます。

manifest.jsonをChromiumに読ませた実測（インストール条件）

この節では、manifest.json の書き方を変えたときに、Chromium がどう読み、インストールできる条件を満たすかどうかが、13通りの実測で分かります。

web.dev の「What does it take to be installable?」によると、Chrome でアプリとしてインストールできる条件は、HTTPS で配信していること、マニフェストに short_name か name・192px と 512px のアイコン・start_url・fullscreen / standalone / minimal-ui / window-controls-overlay のいずれかの display があること、prefer_related_applications が無いか false であること、そしてページを1回以上クリックし合計30秒以上見ていること、です（127.0.0.1 などのローカルホストは、ブラウザが安全な接続と同じに扱います）。手元では、このうちマニフェストに関わる部分を、Chromium が開発者ツールに出すのと同じ「インストールできない理由」の一覧で確かめました。

記録に使ったスクリプトの中心部分です。

const cdp = await ctx.newCDPSession(page);
await page.goto('http://127.0.0.1:22500/full/index.html');
const m  = await cdp.send('Page.getAppManifest');          // 読み取りの結果
const ie = await cdp.send('Page.getInstallabilityErrors'); // インストールできない理由
console.log(m.errors.map(e => e.message), ie.installabilityErrors.map(e => e.errorId));

注：name と short_name を両方消したときの errorId は manifest-missing-name-or-short-name でした。実測から分かったことを整理します。

• 値の誤りは「無視」、形の誤りは「全滅」。display や theme_color に知らない値を書いても、その項目だけが無視され、ほかの項目は読まれました。一方、カンマが1つ多いだけで JSON として読めなくなり、名前もアイコンも start_url もすべて「無い」扱いになって、6件の理由がまとめて出ました。
• name と short_name はどちらか片方でよい。name を消して short_name だけにしても条件を満たしました。両方消すと上の注の理由が出ます。
• アイコンは「144px 以上」が最低線、推奨は 192px と 512px。Chromium は最小 144px を求める理由を返しました。web.dev の条件は 192px と 512px を含めることなので、両方を用意しておけば迷いません。
• sizes の宣言と画像の大きさの食い違いは、この一覧では見つからない。192px の画像を "512x512" と書いても理由は出ませんでした。インストール後のアイコンがぼやける原因になるため、自分で画像の大きさを確かめます。
• Service Worker がなくても条件を満たした。見本には入れていませんが、理由の一覧は空でした。オフラインで動かすには別に用意します。
• シークレット相当の状態では判定できない。使い捨てのプロファイルで開くと、どのページでも in-incognito だけが返りました。

コメント入りの manifest は Chromium では読めましたが、仕様は JSON の形式を定めています。Python の json モジュールで同じファイルを読むと Expecting property name enclosed in double quotes: line 7 column 3 (char 97) で失敗しました。ほかのブラウザやビルドツールでは読めない可能性があるため、Web アプリのマニフェストにはコメントを書かないのが安全です。

ブラウザ拡張機能のmanifest.json

この節では、Chrome などの拡張機能に置く manifest.json の必須項目と、書き誤ったときに出るエラーの原文が分かります。

拡張機能のマニフェストは、拡張機能のフォルダーの一番上に必ず manifest.json という名前で置く、拡張機能の身分証のようなファイルです。Chrome for Developers のマニフェストのリファレンスでは、必須の項目は manifest_version・name・version の3つで、manifest_version に使える値は3だけです。Chrome ウェブストアに出すときは description と icons も要ります。MDN（Firefox の WebExtensions）も同じ3つを必須とし、「JSON 形式だが // 形式のコメントは許される」と書いています。

{
  "manifest_version": 3,
  "name": "RJC 文字数カウンター",
  "version": "1.0.0",
  "description": "選択した文字の数を数える練習用の拡張機能",
  "action": { "default_title": "文字数を数える" },
  "background": { "service_worker": "sw.js" },
  "permissions": ["storage"]
}

この見本を Chromium 153 に --load-extension で読み込ませると、拡張機能の Service Worker が chrome-extension://pbhieidemeabmhmnjomkiohgicoghfmm/sw.js で起動し、その中から chrome.runtime.getManifest() を呼ぶと、書いた name・version・manifest_version がそのまま返りました。続いて、マニフェストを1か所ずつ壊して読み込ませたときのエラーです。

どのエラーも、先頭に Failed to load extension from: （フォルダーのパス）. が付いて記録されました。Web アプリのマニフェストと違い、拡張機能のマニフェストは1か所でも誤ると拡張機能そのものが読み込まれません。また、拡張機能の version は「1〜4個の整数をドットで区切ったもの」で、1.0.0-beta のような書き方は使えないことがエラー文から読み取れます。

Manifest V2 については、Chrome for Developers のサポート終了の予定表で、Chrome 138 が Manifest V2 の拡張機能を動かせる最後の版とされ、2026年8月31日には Chrome ウェブストアから残りの Manifest V2 の拡張機能が取り除かれる予定と書かれています。以前の版の解説にある "manifest_version": 2 の見本は、そのままでは読み込まれません。なお、展開したフォルダーから読み込んだ拡張機能の ID は、フォルダーの場所を変えると別の値になりました。

Kubernetesのマニフェストとは

この節では、Kubernetes で「マニフェスト」と呼ぶものの意味と、必ず書く4つの項目が分かります。

Kubernetes のマニフェストは、作りたいリソース（Deployment・Service など）の「望ましい状態」を YAML か JSON で書いたファイルです。Kubernetes の用語集では、マニフェストは1つ以上の API オブジェクトを JSON か YAML で表した仕様で、apply したときに Kubernetes が保つべき望ましい状態を示すもの、YAML なら1つのファイルに複数のマニフェストを入れられる、と説明されています。公式ドキュメント「Objects In Kubernetes」では、慣習として YAML で書き、kubectl apply -f で送ると例示しています。

Kubernetes のオブジェクトは「意図の記録（record of intent）」で、一度作ると Kubernetes はそのオブジェクトが存在し続けるように働き続けます。たとえば replicas: 2 と書けば、Pod が1つ落ちても2つに戻そうとします。この点が、書いた内容を一度読んで終わりの manifest.json や MANIFEST.MF との大きな違いです。

手元で検証に使った、Deployment と Service の2つを1ファイルにまとめたマニフェストです。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

PyYAML で読むと、--- で区切った2つの文書が別々のオブジェクトとして取り出され、apps/v1 Deployment web と v1 Service web が出力されました。Deployment・Service・Ingress などの書き方を一通り学ぶなら、関連記事「Kubernetes入門｜主要リソースとYAMLの書き方、kubectl早見表」で扱っています。環境ごとにマニフェストの一部だけを変えたい場合は、関連記事「Kustomizeの使い方｜base・overlay・patchの書き方」で扱っています。この記事は「マニフェストとは何か」と、書いたものを確かめる方法に絞ります。

Kubernetesマニフェストを検証する（kubectlなしで実測）

この節では、Kubernetes のマニフェストの誤りを、クラスターに送る前にどこまで見つけられるかが、8通りの実測で分かります。

kubectl は、kubectl apply --dry-run=server でクラスターに保存せずに検証させることができ、--validate は strict（true と同じ）・warn・ignore（false と同じ）を受け付けます。公式ドキュメントによると、Kubernetes 1.25 以降の API サーバーは知らない項目や重複した項目を見つけられ、既定は --validate=true（strict）です。この環境では kubectl とクラスターを用意できなかったため、Kubernetes の API の JSON Schema で手元検証する kubernetes-validate を使い、どんな誤りが「送る前に」見つかるかを確かめました。

python3 -m venv venv
./venv/bin/pip install kubernetes-validate
./venv/bin/kubernetes-validate --strict ok.yaml

INFO ok.yaml passed for resource deployment/web against version 1.37
INFO ok.yaml passed for resource service/web against version 1.37

見本を1か所ずつ壊した結果です。「通常」は --strict なし、「strict」は知らない項目も誤りにする設定です。

この表から、マニフェストの誤りは3つの層に分けて考えると整理できます。

1. 1YAML として読めるか字下げのずれ・タブ。行と列の番号つきで、どの検証でも必ず止まる
2. 2スキーマに合っているか型の誤り・必須項目の抜けは通常でも見つかる。つづり違いは strict でないと見逃す
3. 3意味として正しいかselector とラベルの食い違いなどは、スキーマでは通る。API サーバーやクラスターでないと分からない

注意したいのは2つです。1つ目は、つづり違いの replica が通常の検証を通ったことです。知らない項目を許す設定では、replica は「余計な項目」として素通りし、replicas は書かれていない扱いになります（Deployment の replicas の既定値は1）。クラスターに送ったときに知らない項目を誤りにするかどうかは、上で書いた kubectl の --validate の設定で決まります。

2つ目は、削除された apiVersion が「警告だけ・終了コード0」で通ったことです。Deployment の extensions/v1beta1 は Kubernetes 1.16 で提供が終わっており、今のクラスターに送れば受け付けられません。検証ツールの出力は、終了コードだけでなく WARN の行も読む必要があります。Deployment の公式ドキュメントには、.spec.selector は .spec.template.metadata.labels と一致しなければ API に拒否されると書かれていて、3つ目の層の誤りはクラスター側で初めて止まります。

Javaのjarのマニフェスト（MANIFEST.MF）

この節では、jar ファイルの中にあるマニフェストの役割と、「no main manifest attribute」が出る理由と直し方が、実測で分かります。

jar のマニフェストは、jar（Java のプログラムをまとめた zip 形式のファイル）の中の META-INF/MANIFEST.MF に置かれる、「名前: 値」の行を並べたテキストです。Oracle の JAR File Specification では、java -jar で起動するときに最初に読み込むクラスを Main-Class に、一緒に読むライブラリを Class-Path に書くと定めています。Main-Class にはクラス名だけを書き、.class は付けません。1行は UTF-8 で72バイトまでで、超える場合は先頭に半角スペース1つを置いた続きの行にします。

手元で、Main-Class を書かずに jar を作って起動した結果です。

$ javac Hello.java
$ jar --create --file nomain.jar Hello.class
$ java -jar nomain.jar
no main manifest attribute, in nomain.jar
$ unzip -p nomain.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: 21.0.12.1 (Ubuntu)

jar ツールは、何も指定しなくても MANIFEST.MF を自動で作ります。ただし中身は Manifest-Version と Created-By だけで、Main-Class がないため java -jar は起動するクラスが分からず、終了コード1で止まりました。Main-Class を書いたファイルを --manifest で渡すと起動します。

$ printf 'Main-Class: Hello\n' > m.txt
$ jar --create --file ok.jar --manifest m.txt Hello.class
$ java -jar ok.jar
Hello from jar

ここで、同じ1行を改行なしで書くと、結果が変わります。

$ printf 'Main-Class: Hello' > m2.txt
$ jar --create --file nonl.jar --manifest m2.txt Hello.class
$ java -jar nonl.jar
no main manifest attribute, in nonl.jar
$ unzip -p nonl.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Created-By: 21.0.12.1 (Ubuntu)

最後の行に改行がないと、その行はマニフェストに取り込まれず、エラーも警告も出ませんでした。エディターで MANIFEST.MF を手書きするときは、最後の行の後ろで必ず改行しておきます。なお、jar ツールが書き出した MANIFEST.MF の改行は CR LF（cat -A で ^M$ と表示）でした。Maven や Gradle で作る場合は、ビルドの設定から Main-Class を指定する方法が一般的です。jar の作り方と Class-Path の書き方は、関連記事「Java jarファイルの作成と実行方法｜クラスパス指定とMain-Class」で扱っています。

AndroidManifest.xml・コンテナイメージのマニフェスト

この節では、Android アプリとコンテナイメージのマニフェストが何を宣言するのかが、公式の説明の範囲で分かります。

AndroidManifest.xml は、すべての Android アプリのプロジェクトで、ソースセットの直下にこの名前のまま置く XML ファイルです。Android Developers の「アプリ マニフェストの概要」によると、ビルドツール・Android OS・Google Play にアプリの情報を伝えるもので、主に次の3つを宣言します。

• アプリのコンポーネント：activity・service・receiver・provider。宣言していないものはシステムが起動できません。
• 権限：保護された機能を使うための uses-permission。実行時に利用者が許可するしくみ（Android 6.0 以降）があっても、宣言は必須です。
• 端末の条件：必要なハードウェア・ソフトウェアの機能（uses-feature）。Google Play でインストールできる端末が決まります。

パッケージ名は、現在の公式の説明ではマニフェストではなく build.gradle の namespace で指定し、.MainActivity のような点で始まる名前に補われます。

コンテナイメージのマニフェストは、1つのイメージがどの設定（config）とどのレイヤーから成り立つかを、ハッシュ値（ダイジェスト）で並べた JSON です。OCI Image Format Specification では、schemaVersion は2、メディアタイプは application/vnd.oci.image.manifest.v1+json と定めています。「同じタグなのに中身が違う」ときに確かめる対象になります。

自分のマニフェストを確かめる方法

この節では、手元のサイトやファイルのマニフェストを、ブラウザの開発者ツールやターミナルの1行で確かめる方法が分かります。

自分で確かめる（1）ブラウザの開発者ツールで1行。確かめたいページを開き、開発者ツール（Windows・Linux は F12、Mac は Command＋Option＋I）のコンソールに次の1行を入力します。manifest へのリンクがあれば完全な URL が、なければ undefined が返ります。

document.querySelector('link[rel="manifest"]')?.href

// 見本のページ
'http://127.0.0.1:22500/full/manifest.webmanifest'
// link を書かなかったページ
undefined

中身とサーバーの返し方まで見るなら、続けて次の1行です。手元では status 200、application/manifest+json、書いたとおりの name・icons が返りました。

await fetch(document.querySelector('link[rel="manifest"]').href).then(async r => ({status: r.status, type: r.headers.get('content-type'), body: await r.json()}))

Chrome の開発者ツールには、Application パネルの Manifest の画面があり、読み込んだ値・アイコン・インストールできない理由を一覧で見られます（Chrome for Developers の説明）。前の節の実測で使った errorId は、この画面に出る理由と同じ仕組みから取り出したものです。

自分で確かめる（2）ターミナルで1行。JSON として正しいかは、Python の標準機能で確かめられます。正しければ整形して表示され、誤りがあれば行と列が出ます。

$ python3 -m json.tool manifest.webmanifest > /dev/null && echo OK
Expecting property name enclosed in double quotes: line 7 column 27 (char 121)

$ python3 -m json.tool manifest.json        # 拡張機能（末尾にカンマ）
Illegal trailing comma before end of object: line 8 column 29 (char 235)

Chromium が「line 7, column 27」と返した誤りを、Python も同じ位置で見つけています。jar のマニフェストは unzip -p アプリ.jar META-INF/MANIFEST.MF、Kubernetes のマニフェストは前の節の kubernetes-validate --strict で確かめられます。クラスターに作られたものを見るなら、kubectl get deployment web -o yaml で、Kubernetes が補った既定値や status まで含めたマニフェストが表示されます（公式ドキュメントの説明）。

• 1どのマニフェストかを先に決めるWeb アプリか拡張機能か Kubernetes か jar か。同じ名前でも項目が違う
• 2形が正しいかを機械で確かめるjson.tool・YAML のパーサー。1文字の誤りで全体が読めなくなる
• 3読む側が実際に読んだ値を見る開発者ツールの Manifest、getManifest、kubectl get -o yaml
• 4警告の行まで読む「無視した」「スキーマがない」は終了コード0でも出る

マニフェストのよくあるエラー・つまずき

この節では、マニフェストでよく見るエラーの原文と、原因・直し方の対応が分かります。

YAML の字下げや型の落とし穴（"yes" や 0 で始まる数字など）は、関連記事「YAMLの書き方｜構文一覧とパース結果、落とし穴10例を実測」で扱っています。

マニフェストの書き方・確かめ方の判断表

この節では、やりたいことに合わせて、どのマニフェストをどう書き、何で確かめればよいかが分かります。

どの形式でも、「書いた内容」と「読む側が実際に読んだ値」を分けて確かめると、原因の分からない不具合を減らせます。

マニフェストのよくある質問

この節では、マニフェストについてよく聞かれる疑問への答えが分かります。

Q. マニフェストとは、簡単に言うと何ですか？
中身についての説明書き（積荷目録）です。プログラム本体とは別のファイルに、名前・版・設定・必要な権限などを書き、ブラウザ・Kubernetes・JVM などがそれを読んで扱い方を決めます。

Q. manifest.json と manifest.webmanifest はどちらにすべきですか？
Web アプリのマニフェストなら、どちらでも動きます。仕様が登録している拡張子は .webmanifest、推奨のメディアタイプは application/manifest+json です。拡張機能のマニフェストは manifest.json という名前が決まっていて、変えられません。

Q. manifest.json を置いたのに「インストール」が出ません。
開発者ツールの Application → Manifest でインストールできない理由を見ます。手元の実測では、アイコンの不足・display: browser・start_url が別オリジン・JSON の形の誤りで、それぞれ理由が出ました。理由が空でも、ページを1回以上クリックして30秒以上見ていないと、インストールの案内は出ません（web.dev の条件）。シークレットウィンドウでは判定されません。

Q. Kubernetes のマニフェストは YAML でないといけませんか？
JSON でも書けます。公式ドキュメントでは、慣習として YAML で書くと説明されています。YAML は --- で区切って1つのファイルに複数のリソースを入れられ、コメントも書けるため、手で書く場合は YAML が使われることが多くなっています。

Q. Kubernetes のマニフェストをクラスターなしで確かめる方法はありますか？
YAML の形と API のスキーマに合っているかは、手元で確かめられます。この記事では kubernetes-validate を使い、型の誤りや必須項目の抜けを見つけられました。ただし、selector とラベルの食い違いのような意味の誤りはスキーマでは見つからず、API サーバー（kubectl apply --dry-run=server など）で確かめる必要があります。

Q. マニフェストファイルはどうやって開けばいいですか？
中身はテキストなので、メモ帳や VS Code などのテキストエディターで開けます。jar の中の MANIFEST.MF は、jar が zip 形式なので unzip -p や zip を開けるソフトで読めます。Excel などの表計算ソフトで開く形式ではありません。

Q. 「no main manifest attribute」はどう直せばいいですか？
jar のマニフェストに Main-Class: クラス名 を書いて jar を作り直します。手書きの場合は、最後の行の後ろで改行しているかを確かめます。手元の実測では、改行がないだけで Main-Class が消え、同じエラーになりました。

Q. 政治のマニフェストと IT のマニフェストは関係がありますか？
直接の関係はありません。政治のマニフェストは政権公約のことで、英語の manifesto にあたります。IT のマニフェストは「積荷目録」の意味の manifest から来ていて、どちらも「中身をはっきり示す」という語感だけが共通しています。

まとめ

• マニフェストとは、中身と扱い方を読む側のプログラムに伝える宣言のファイル。Web アプリ・拡張機能・Kubernetes・jar・Android で、ファイル名も書式も読む側も違う。
• Web アプリの manifest.json は、Chromium 153 で name か short_name・144px 以上（推奨は 192px と 512px）のアイコン・start_url・対応した display があれば、インストールの条件を満たした。Service Worker はなくても理由は出なかった。
• 知らない値は黙って無視され、JSON の形の誤りは全項目を無効にした。拡張機能はマニフェストの誤り1つで読み込まれず、manifest_version 2 は unsupported manifest version で止まった。
• Kubernetes のマニフェストは、YAML の形・スキーマ・意味の3層で確かめる。つづり違いは strict でないと通り、削除された apiVersion は警告だけで終了コード0だった。
• jar の MANIFEST.MF は、最後の行に改行がないと Main-Class が消えて「no main manifest attribute」になる。どの形式でも、読む側が実際に読んだ値を1回は見て確かめる。

参考・出典

確認日はいずれも 2026年10月29日です。

• W3C「Web Application Manifest」（Working Draft）：https://www.w3.org/TR/appmanifest/
• MDN「ウェブアプリマニフェスト」：https://developer.mozilla.org/ja/docs/Web/Progressive_web_apps/Manifest
• web.dev「What does it take to be installable?」：https://web.dev/articles/install-criteria
• Chrome for Developers「Manifest file format」（拡張機能）：https://developer.chrome.com/docs/extensions/reference/manifest
• Chrome for Developers「Manifest V2 support timeline」：https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline
• MDN「manifest.json」（WebExtensions）：https://developer.mozilla.org/ja/docs/Mozilla/Add-ons/WebExtensions/manifest.json
• Kubernetes「Objects In Kubernetes」：https://kubernetes.io/docs/concepts/overview/working-with-objects/
• Kubernetes 用語集「Manifest」：https://kubernetes.io/docs/reference/glossary/?all=true#term-manifest
• Kubernetes「kubectl apply」リファレンス：https://kubernetes.io/docs/reference/kubectl/generated/kubectl_apply/
• Kubernetes「Deployments」：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
• Kubernetes「Deprecated API Migration Guide」：https://kubernetes.io/docs/reference/using-api/deprecation-guide/
• Oracle「JAR File Specification」（Java SE 21）：https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html
• Android Developers「アプリ マニフェストの概要」：https://developer.android.com/guide/topics/manifest/manifest-intro?hl=ja
• Open Container Initiative「OCI Image Manifest Specification」：https://github.com/opencontainers/image-spec/blob/main/manifest.md
• kubernetes-validate 1.37.0（PyPI）：https://pypi.org/project/kubernetes-validate/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。