JSON と JSON5 の違い

JSON と JSON5 は見た目は似ていますが、「どれくらい人間に優しいか」「どれくらい厳格か」で大きく違います

 

🧩 JSONとは

JavaScript Object Notation の略で、
データ交換フォーマットとして最も一般的なものです。

 

✅ 特徴

・厳格でシンプル
・仕様が固定されていて機械処理に最適
・ほとんどの言語・ツールが標準対応

 

📋 制約


{
  "name": "Mao",
  "age": 25,
  "languages": ["Swift", "Kotlin"]
}

・文字列は必ず ダブルクォート
・コメント不可
・末尾カンマ禁止
・キーもクォート必須
・数値表現 は10進数のみ

 

🌈 JSON5とは

JSON for Humans(人間に優しいJSON)で
JSONの上位互換として提案されたフォーマットです。

JavaScriptライクな書き方を許します。

 

✅ 特徴

・より柔軟で可読性が高い
・コメントや末尾カンマをサポート
・キーや文字列のクォート省略OK
・16進数や+∞などの数値表現が可能

 

📋 例


{
  // コメントOK
  name: 'Mao',
  age: 25,
  languages: ['Swift', 'Kotlin',], // 末尾カンマOK
  version: 0x1f, // 16進数OK
}

 

🤔 JSON と JSON5 の比較

JSON は機械向けの厳格フォーマット、JSON5 は「人間向け」に拡張されたフォーマットです。下の表はブログでそのまま使える比較表です。

項目 JSON JSON5
コメント 不可(コメントなし) 可(`//`、`/* */` が使える)
末尾カンマ 不可
キーのクォート 必須(ダブルクォート) 省略可(識別子としてのキーを許可)
文字列のクォート ダブルクォートのみ(`"`) シングルクォートまたはダブルクォート可(`'` / `"`)
数値表現 10進数のみ 10進数、16進数、`NaN`、`Infinity` などを許可
対応ツール 非常に多い(ほぼ標準) ライブラリが必要(サポートは限定的)
用途 機械間通信(API等)に最適 開発者向け設定ファイルや手で編集するデータに適する

 

🧑🏻‍💻 まとめ

- JSON:厳格で機械向け。安全・標準的。
- JSON5:柔軟で人間向け。コメントや末尾カンマOK。


Kotlin・KSP・Compose Compiler を安全に更新する Renovate 設定術(developブランチ運用編)

Jetpack Compose Compiler が Kotlin に強く依存していた時代を経て、
今では少しずつ依存関係が緩やかになってきました。
それでも Kotlin・KSP・Compose Compiler の3つは依然として密接に関係しており、
バージョンのズレひとつでビルドが崩壊するリスクがあります。

この記事では、develop ブランチをメインに運用しつつ、
それらを安全かつ一貫性を保って更新するための Renovate 設定を紹介します。

 

🧩 Kotlin・KSP・Compose Compiler の三位一体更新

Compose Compiler は Kotlin コンパイラと深く結びついて動作するため、
Kotlin のメジャーアップデートが入ると、それに対応した Compose Compiler が必要になります。

さらに、KSP(Kotlin Symbol Processing)も Kotlin バージョンに追随するため、
この3つは基本的に「セットで更新する」のが鉄則です。


{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "baseBranches": ["develop"],
  "packageRules": [
    {
      "groupName": "Kotlin, KSP and Compose Compiler",
      "groupSlug": "kotlin",
      "matchPackagePrefixes": [
        "com.google.devtools.ksp",
        "org.jetbrains.compose.compiler"
      ],
      "matchPackagePatterns": [
        "org.jetbrains.kotlin.*"
      ]
    },
    {
      "description": "Do not automerge without CI",
      "matchUpdateTypes": ["minor", "patch", "digest"],
      "automerge": false
    }
  ]
}

 

⚙️ 設定の意図を読み解く

この設定は、単に自動更新を行うだけでなく、
Kotlin 界隈の依存を安全に、かつチームの開発フローに合わせて管理することを意識しています。


baseBranches: ["develop"]

Renovate のデフォルトは main や master に対して PR を作りますが、
実際の開発フローでは「開発用ブランチ(develop)」に更新を入れたいケースが多いですよね。

"baseBranches": ["develop"] を指定しておくことで、
更新 PR が常に develop ブランチに向けて作成されるようになります。

本番リリース前にテストや検証を挟める安全設計です。

 

🔗 groupName: 三つ巴のアップデートを1つにまとめる

groupName は、関連する依存をひとまとめにするためのグループ名。
ここでは "Kotlin, KSP and Compose Compiler" としており、
3つのパッケージを同時に1つの PR にまとめてくれます。


"matchPackagePrefixes": [
  "com.google.devtools.ksp",
  "org.jetbrains.compose.compiler"
],
"matchPackagePatterns": [
  "org.jetbrains.kotlin.*"
]

この指定で次のような依存が同時更新対象になります:


- Kotlin (org.jetbrains.kotlin)

- KSP (com.google.devtools.ksp)

- Compose Compiler (org.jetbrains.compose.compiler)

以前は androidx.compose.compiler でしたが、
現在の Compose Multiplatform では org.jetbrains.compose.compiler に移行しているため、この設定がより正確です。

 

🚫 automerge: false の哲学

Renovate には更新を自動マージする機能がありますが、
Kotlin 系の更新はそれに向きません。

理由は単純で、CI でのビルド確認が欠かせないからです。


{
  "description": "Do not automerge without CI",
  "matchUpdateTypes": ["minor", "patch", "digest"],
  "automerge": false
}

「CI による確認を通らない限り、自動マージさせない」というルールです。

特に Kotlin の minor アップデートでは内部 API が変わることもあり、
Compose Compiler や KSP が対応していない可能性があります。

PR を作成したあと CI を通し、問題なければ手動でマージする。

これが最も安全な流れです。

 

🧭 運用のヒントとまとめ

この設定は、いわば「Kotlin エコシステム用 Renovate セーフティモード」。

自動化の恩恵を受けつつも、壊れやすい依存を慎重に扱うための現実的な妥協点です。

項目 意図
baseBranches 更新PRをdevelop向けにして安全確認を確保
groupName Kotlin / KSP / Compose Compiler を同時に更新
automerge: false CI確認なしでの自動マージを防止
matchPackagePrefixes / matchPackagePatterns 最新の Compose 構成(Compose Multiplatform 等)に対応

 

🪶 まとめ:安全第一の Renovate 運用へ

Renovate は「ただの自動更新ボット」ではなく、
チームのアップデート戦略をコード化できるツールです。

Kotlin、KSP、Compose Compiler のような密接な関係を持つ依存こそ、
グルーピングとマージ制御で慎重に扱うべき対象。

develop ベースで CI を通すこの設定は、
自動化と安全性のバランスを取る最適解のひとつと言えます。

👉 Renovate Docs


【AppleCare に未加入】クレカ付帯の保険でiPhone画面ひび割れをAppleで5000円で修復する方法

iPhoneの画面をうっかり割ってしまったとき、高額な修理代にため息をついたことはありませんか?実は、クレジットカードに付帯している保険を活用すれば、Appleの正規修理でも実質5000円で済むことがあります。

この記事では、「クレカの保険でiPhone画面をお得に修理する方法」について、仕組み・対応カード・実際の流れを解説します。

 

🤔 これで私も、実質19400円 → 5000円 となりました。

手が滑って画面がひび割れてしまった iPhone が、

Apple 作業にて、実質支払5000円で復活。

 

🤔 スマホの画面割れは「クレカの保険」でカバーできる

多くのクレジットカードには「ショッピング保険」や「スマートフォン保険」が付帯しており、購入後一定期間内の破損や盗難などを補償してくれます。中でも注目すべきは、アメリカン・エキスプレス(AMEX)のスマートフォン・プロテクションです。


🔹 AMEXスマートフォン・プロテクションの主な特徴

対象機種          購入後36ヶ月以内のスマートフォン
補償額	        年間最大5万円(自己負担5,000円)
対象となる損害	破損、火災、水濡れ、盗難
条件             スマホの通信料をAMEXカードで3ヶ月以上連続して支払っていること
対象カード        AMEXゴールド・プラチナ・ANAプレミアムなど

この保険を利用すれば、Apple公式で修理しても5,000円の自己負担で済み、残りはAMEXが補償してくれます。たとえば、iPhoneの画面修理に30,000円かかったとしても、あなたの負担は5,000円で済むというわけです。

 

🤔 他にも使える「ショッピング保険付きクレカ」とその条件

スマートフォン・プロテクション以外にも、ショッピング保険があるクレカで補償できる場合があります。ポイントは、「スマホをそのカードで購入したかどうか」と「支払方法(リボ・分割など)」です。

以下は代表的なクレジットカードと補償内容の比較です:


カード名                  補償条件         年間補償額  自己負担額  備考
JCBゴールド               90日以内の購入品  500万円    3,000円    通常の支払いOK
三井住友カード(ゴールドNL) リボ・分割払いのみ 300万円    3,000円    一括払いは対象外
楽天プレミアムカード        購入90日以内     300万円    3,000円    通常カードは対象外
エポスゴールドカード        90日以内         300万円   3,000円    招待で年会費無料も可能

注意点
購入日から90日以内であることが多い

修理費を出しても実際に補償されるのは“クレカで払った分の修理”

キャリア一括払いやApple Store以外の購入は対象外になることもある

 

🤔 実際の流れ:iPhoneの画面割れを5000円で修理するまで

では、実際にAMEXのスマートフォン・プロテクションを使って修理する手順をまとめます。


🔧 ステップ①:AMEXの補償条件を満たしているか確認

  - iPhone購入から36ヶ月以内
  - 通信料をAMEXカードで3ヶ月以上支払っている
  - AMEX対象カードを持っている(ゴールドやプラチナ等)


🔧 ステップ②:Apple公式で修理(または正規修理プロバイダ)

  - Apple StoreまたはApple正規サービスプロバイダで画面修理を行う
  - 修理費の領収書を保管


🔧 ステップ③:AMEXに保険金請求

  以下のものを用意し、所定のフォームから申請します:

  - 修理の領収書 or 見積書
  - 損害の状況を記載した説明書
  - 通信料のAMEXカード支払い履歴
  -(盗難時)警察の届け出番号

申請が認められると、AMEXから修理費用のうち5,000円を超えた分が口座に振り込まれます。

 

🤔 まとめ:クレカ保険を知っていれば、画面割れも怖くない

iPhoneの画面が割れたとき、修理費が高くて悩む人は多いですが、クレカの保険を知っていれば5,000円で済む可能性が十分にあります。

特にAMEXスマートフォン・プロテクションは、通信料支払いという条件さえ満たせば、iPhoneを購入してから3年間はいつでも補償が受けられる強力なサービスです。

AppleCare+に入っていない人でも、AMEXカードを持っていれば安心して修理できます。これを機に、あなたのクレカに保険が付いているか、ぜひ一度確認してみてください。

👉 スマートフォン・プロテクション | クレジットカードはアメリカン・エキスプレス(アメックス)


【curl】 Note: Unnecessary use of -X or --request, POST is already inferred.


❯ curl -X POST "https://httpbin.org/post" -H "accept: application/json"


Note: Unnecessary use of -X or --request, POST is already inferred.

-d や --data があると自動で POST と判断するので -X POST などは不要だって。


❯ echo '{
  "user_id" : 123,
  "name" : "ワロ田",
  "age" : 14
}' | curl -vs -H 'Content-Type: application/json; charset=UTF-8' -H 'Accept: application/json' -d @- https://httpbin.org/post
* Host httpbin.org:443 was resolved.
* IPv6: (none)
* IPv4: 54.152.142.77, 3.224.7.64, 35.172.19.140, 34.238.6.191
*   Trying 54.152.142.77:443...
* Connected to httpbin.org (54.152.142.77) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=httpbin.org
*  start date: Aug 20 00:00:00 2024 GMT
*  expire date: Sep 17 23:59:59 2025 GMT
*  subjectAltName: host "httpbin.org" matched cert's "httpbin.org"
*  issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://httpbin.org/post
* [HTTP/2] [1] [:method: POST]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: httpbin.org]
* [HTTP/2] [1] [:path: /post]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [content-type: application/json; charset=UTF-8]
* [HTTP/2] [1] [accept: application/json]
* [HTTP/2] [1] [content-length: 55]
> POST /post HTTP/2
> Host: httpbin.org
> User-Agent: curl/8.7.1
> Content-Type: application/json; charset=UTF-8
> Accept: application/json
> Content-Length: 55
>
* upload completely sent off: 55 bytes
< HTTP/2 200
< date: Sun, 13 Apr 2025 03:08:32 GMT
< content-type: application/json
< content-length: 557
< server: gunicorn/19.9.0
< access-control-allow-origin: *
< access-control-allow-credentials: true
<
{
  "args": {},
  "data": "{  \"user_id\" : 123,  \"name\" : \"\u30ef\u30ed\u7530\",  \"age\" : 14}",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Content-Length": "55",
    "Content-Type": "application/json; charset=UTF-8",
    "Host": "httpbin.org",
    "User-Agent": "curl/8.7.1",
    "X-Amzn-Trace-Id": "Root=1-67fb2ab0-3685bdfa4519f20b0d94c818"
  },
  "json": {
    "age": 14,
    "name": "\u30ef\u30ed\u7530",
    "user_id": 123
  },
  "origin": "114.123.123.8",
  "url": "https://httpbin.org/post"
}
* Connection #0 to host httpbin.org left intact


❯ echo '{
  "user_id" : 123,
  "name" : "ワロ田",
  "age" : 14
}' | curl -s -H 'Content-Type: application/json; charset=UTF-8' -H 'Accept: application/json' -d @- https://httpbin.org/post | jq
{
  "args": {},
  "data": "{  \"user_id\" : 123,  \"name\" : \"ワロ田\",  \"age\" : 14}",
  "files": {},
  "form": {},
  "headers": {
    "Accept": "application/json",
    "Content-Length": "55",
    "Content-Type": "application/json; charset=UTF-8",
    "Host": "httpbin.org",
    "User-Agent": "curl/8.7.1",
    "X-Amzn-Trace-Id": "Root=1-67fb2b2f-6faa217ece89a13acc5315"
  },
  "json": {
    "age": 14,
    "name": "ワロ田",
    "user_id": 123
  },
  "origin": "114.123.123.81",
  "url": "https://httpbin.org/post"
}

Form からの POST があるので

リクエストヘッダは2つつけたほうが

「JSON の POST ですよ」

とはっきり明示できそうです。

 

🧑🏻‍💻 参考



Obsidian エディター の モード切替え


Obsidian。

すごく便利です。

しかし、エディターの切替えがなんか謎。

整理してみました。

 

🤔 エディターの種類

そもそも、これの「表示スタイル」の種類が何個あるのか。

設定画面を見ると、

タブの「Default View」の選択肢2個。

「Editing view」のデフォルトの選択肢が2個。


- Editing view
- Reading view
- Live Preview
- Source mode

4つもあるんですかね ???

どうやって切り替えるのかよくわからん。

 

🤔 調べてみた

画面の表示形式は、3つです。


Tab
  + Editing view
    + Live Preview (1)
    + Source mode  (2)
  + Reading view   (3)

「Live Preview」 は、

編集しながら対象テキストのフォーカスを動かしながら、プレビューができる。

「Source mode」 は、編集のみできてプレビューはできない。

「Reading View」 は、プレビューのみで編集はできない。

 

🤔 切り替え方法

これが分かりづらい。

右上の2つのアイコンからです。

動的なトグル付き選択肢がなんか分かりづらい感じがします。

👉 【Git】Obsidian を GitHub と連携する