私が書かないと決めていること

書き手が何を信じているかを最も早く読み取る方法は、書こうと思えば書けたのに書かないと選んだ事柄のリストを見ることです。投稿量は、何が出版されたかを教えてくれます。拒否のリストは、立場を示すものとなります。明確な拒否リストを持つブログは一人の人間として読めますが、それのないブログはフィードとして読めるのみです。

Apple Ecosystem クラスターには声があります。その声は、出版された記事によって主に形作られているのではありません。出版されなかった記事、そして名目上はテーマに沿っているはずなのに結局カットされた、繰り返し現れる文章の形によって形作られているのです。クラスター全体で読まれてきた記事は、すべてカットの下流にあります。本稿の残りは、そのカットに名前を与えていきます。

区別すべき拒否には2種類あります。カテゴリー的拒否とは、クラスターの領域外にあるトピックのことです。パターン的拒否とは、トピックに関係なく草稿を不適格にしてしまう声と構造の選択を指します。前者は趣味の問題、後者は技芸の問題です。両方が、あなたの読むものを形作っているのです。

TL;DR

カテゴリー的拒否：Apple スタックとエージェントの交差点に含まれないものすべて。一般的な web 開発、クラウド LLM チュートリアル、採用関連技術など、クラスターのアイデンティティを薄めるものはすべて該当します。
パターン的拒否：使い回しのセットアップ語り（「120 個のフックから学んだこと」）、証拠としての非公開テレメトリー、編集的な足場（プランニングラベル、PRD 番号）、アーキテクチャを伴わないチュートリアル、根拠のない過激な意見。
興味深い拒否：クラスターの名目上の領域内にありながら、立場を強化しないためカットされるトピック（visionOS の生産性アプリ、サーバーサイド Swift、AppKit 専用の Mac UI など）。
拒否は不在ではありません。拒否は、残されたものの形そのものなのです。

カテゴリー的拒否

このクラスターは、AI エージェントとの交差点にある Apple 開発を扱います。その交差点の外側にあるものはすべて対象外です。それは興味深くないからではなく、複利的に積み上がらないからです。

一般的な web 開発。 Blakecrosley.com 自体は FastAPI と HTMX で動いています。このスタックについて書ける記事は何十本もあります。HTMX のスワップパターン、FastAPI の依存性注入、非同期 SQLAlchemy の落とし穴など。しかしそのいずれもこのクラスターには属しません。クラスターの読者はエージェントを考えている iOS 開発者であり、web 開発の記事は、それ自体が独自の読者を引きつけるとしても信号を薄めてしまいます。そうした記事にはふさわしい場所がありますが、このクラスターはその場所ではないのです。

クラウド LLM API チュートリアル。 Anthropic の API。OpenAI の API。Python の SDK 群。Claude Sonnet と Opus のレイテンシの違い。バックエンドサービスからクラウド LLM を呼び出す方法を学んでいる人向けのチュートリアル形式コンテンツです。クラスターの立場は、エージェント的な Apple こそ希少なものであり、クラウド LLM のチュートリアルはインターネット上の他の場所が十分にカバーしているコモディティだというものです。そうした記事を書くことは、ドキュメントを音読するような作業であり、クラスターの権威に何も加えないでしょう。

ResumeGeni と 941 の採用関連技術。 別会社、別ブランド、別サイトです。両者を交配させることは、両方を弱めることになります。採用スタックには独自の技術的決定（ATS パーサー、埋め込みパイプライン、候補者マッチングアルゴリズムなど）があり、それらは別のアイデンティティの下にある別のブログに属するものであって、ここではありません。

クラスターのアイデンティティを薄めるもの。 Postgres のコネクションプーリングについての本当に良質な記事、JavaScript フレームワークの乱立を批判する Hacker News 風の論考、Rust の非同期ランタイムについての思慮深い文章。すべて擁護できる執筆ですが、すべてクラスターの領域外です。掲載の基準は「記事が良いか」ではありません。基準は「すでにここにあるものに複利的に積み上がるか」なのです。

カテゴリー的拒否は、クラスターのアイデンティティによって決まります。アイデンティティが名指されれば、拒否はそれに従って導かれます。

パターン的拒否

パターン的拒否はトピックを横断します。クラスターのテーマに沿った草稿でも、書き方によって却下されることがあります。

使い回しのセットアップ語り。「6 か月で 120 個のフックと 49 個のコマンドから学んだこと」「500 セッションを経て、3 つのことが残った」「私の 95 個のフック構成」。使い回しのセットアップというパターンは、書き手の執筆環境を専門性の証拠として再利用するものです。クラスターのアプリは小さな集合なので、書き手がそこに頼ると、同じフック数、スキル数、コマンド数、セッション数が記事を重ねるごとに繰り返し現れることになります。読み味としては、議論というよりも咳払いに近いものとなってしまいます。クラスターが落ち着いたルールはこうです。記事の量はフレームワーク解説とフロンティアエッセイに傾け、出荷済みコードに関する記事は、書き手のツール分類ではなく、現実の公開プロジェクトを指し示すこと。

証拠としての非公開テレメトリー。「フックは 34 日で 52 回発火した」「ファントム検証はセッションの 12% から 2% 未満まで下がった」。非公開の数値は外部から検証できず、自慢のように読まれ、いかなる公開された成果物とも照合できません。証拠の正しい形は、公開ソース（Apple Developer のドキュメント、Anthropic の仕様、出荷済みのオープンソースコード、論文）と、それに基づく推論の組み合わせです。非公開の指標が機能するのはコミットメッセージとポストモーテムであって、出版された散文ではありません。

編集的な足場。 書き手の内的分類によって記事を区分する太字のラベル。本文中の PRD 番号。「cave plan ラダーに従って」。読者は、その記事が書き手のプランニング文書のどのバケットに属するかを知る必要はありません。ジャンルは最初の文から明らかとなります。プランはワークフローのツールであって、読者向けのコピーではないのです。成果物は成果物、ワークフローはワークフローのなかにとどまるべきものでしょう。

アーキテクチャを伴わないチュートリアル。「ここに XcodeBuildMCP のインストール方法を示す」と言いつつ、エージェントが構造化されたツールアクセスを持ったときに何がアーキテクチャ的に変わるかを名指しせずに済ませる記事はチュートリアルです。チュートリアルには価値がありますが、クラスターの貢献ではありません。クラスターの貢献は、クラスターの残りの部分と複利的に積み上がるアーキテクチャパターンです。そのレベルに達しないチュートリアルは、達するまで書き直されるか、カットされるかのどちらかとなります。

根拠のない過激な意見。「Codex は Claude Code より優れている」「MCP は過大評価されている」「App Intents は袋小路だ」。過激な意見というジャンルはトラフィックを引きますが、精査に耐えません。真である意見は書き手が見て弁護できる具体的な振る舞いに根ざしていますが、虚偽の意見は同時代の二番目に優秀な開発者がそれを読んだ瞬間に崩れます。クラスターの強い意見の記事（Trust、Tool RL、App Intents vs MCP）は意見ではなく立場であり、立場には領収書が伴うのです。

自明のことを唱える必要があるもの。「まず Xcode をインストールしてください」「npm install を実行してください」「Apple のドキュメントは developer.apple.com にあります」。これらは埋め草です。Xcode のインストール方法を教わる必要のある読者は、クラスターの読者ではありません。クラスターは、読者がすでにそれを読むようなタイプの人間であることを前提にしており、その読者を別の地点で迎えに行くというのは、別のサイトの別の記事の話なのです。

興味深い拒否

カテゴリー的拒否は簡単です。パターン的拒否はルールに従います。興味深い拒否は、クラスターの名目上の領域の内側にありながら、立場を強化しないためにカットされるトピックです。

生産性アプリ向けの visionOS。「visionOS をセカンドスクリーンとして使う」あるいは「Vision Pro でジャーナリングアプリを出荷する」というような長文記事。Apple スタック、テーマ内です。カットされる理由は、クラスターの visionOS に対する立場がRealityKit + 空間的なメンタルモデルこそアーキテクチャ上のレバーであるというものだからです。「visionOS をフラットな生産性のサーフェスとして使う」というのは別フレームワークの領域であり、クラスターを拡張しません。装飾要素、没入空間、ハンドトラッキングについての記事なら複利的に積み上がりますが、「iPad アプリを visionOS で動かす」記事はそうはなりません。

サーバーサイド Swift。 Vapor、Hummingbird、Linux コンテナ内のサーバーサイド Swift。本物で、成長中で、技術的に興味深いものです。クラスターの外です。クラスターのサーバーに関する立場は「iCloud Drive と JSON ファイルと MCP サーバー」、すなわち意図的に小さなサーバーサイドへのコミットメントです。より大きなもの（Swift のバックエンドサービス）は別のアーキテクチャ的な会話であり、エージェント的な Apple のフロンティアと交差しないからです。Swift バックエンドが iOS と AI エージェントのアーキテクチャにとって荷重を担う日が来れば、その記事は場を得ます。今日はそうではないのです。

AppKit 専用の Mac UI。 Mac アプリは今でも深い AppKit の作業を伴って出荷されています。クラスターのマルチプラットフォーム出荷の記事が Mac 上の SwiftUI を扱っていますが、AppKit 固有のトピック（NSToolbar のカスタマイズ、NSResponder チェーンの癖、AppKit から SwiftUI へのブリッジングの落とし穴）はクラスターの声からはわずかに外れます。それらは別のクラスターの立場（具体的には Mac 開発）を強化するほうが、このクラスターを強化するよりも適しているのです。

既に存在するものを超えた比較記事。App Intents vs MCP が枠を得ているのは、その比較がアーキテクチャのルールを明らかにするからです。iOS 開発における Cursor、Zed、JetBrains の比較はトラフィックを引くでしょうが、「異なる IDE は異なる動きをする」以上のものは明らかにしないでしょう。比較記事を追加する基準は、その比較自体がフロンティアエッセイ級の洞察を生み出すか、それとも単なるベンチマークに留まるかどうか、です。

権威を装う必要があるもの。 Core ML チームのメンバーを感心させるほどの技術的深さで Core ML 量子化を扱う記事。グラフィックスエンジニアを感心させるほどの深さで visionOS Metal シェーダを扱う記事。クラスターの権威は、エージェント的な Apple のアーキテクチャの交差点にあります。その交差点の外側に手を伸ばすと、間違いと言われない程度には正しいけれども、複利的に積み上がるほどには深くない記事ができてしまいます。誠実な動きは、より深い声（Core ML 研究者のブログ、グラフィックスエンジニアの解説）を引用することであり、それを演じることではありません。

製品としての拒否

拒否のリストは限界の告白ではありません。拒否のリストはポジショニングの行為です。1984 年の Apple の Mac 広告キャンペーンは、IBM 向けのキャンペーンではないことで有名でした。Steve Jobs の 1998 年の 2x2 グリッド（コンシューマー／プロ × デスクトップ／ポータブル、Mac ライン全体を 4 つの箱に）の時点での Apple の製品ラインは、生き残ったものではなく、カットされたもので有名でした。あるカテゴリーを拒否するという選択は、そこに出荷するという選択よりも強い製品シグナルとなるのです。

書くことにおいても、拒否は同じ仕事をします。クラスターの声（直接的、意見が明確、証拠に基づき、容赦のない正直さのフッターつき）が存在するのは、使い回しのセットアップ語りがカットされ、非公開テレメトリーがカットされ、編集的な足場がカットされ、クラウド LLM チュートリアルがカットされたからです。それぞれのカットは、ポジティブな空間を定義するネガティブスペースなのです。

このパターンはリポジトリは自分自身の信頼に投票する権利を持つべきではないとも響き合います。信頼ダイアログの価値は、ユーザーが承認する前に解釈することを拒否するものから生まれるのです。ワークスペースのバイトを読む信頼ゲートは、ゲートではありません。テーマ内のあらゆる記事に「はい」と答えるブログクラスターは、クラスターではないのです。境界における拒否こそが、成果物に意味を持たせるのでしょう。

帰結として、拒否リストを持たない書き手も別に問題はありませんが、その人が生み出しているのはフィードであって立場ではありません。両方とも本物の成果物です。しかし時間を経て権威を蓄積するのは一方だけなのです。

Apple スタックのフロンティアにいる書き手にとっての含意

3 つの教訓となります。

カテゴリー的拒否を最初に名指す。 クラスターの領域の外にあるものは何か。リストを書きましょう。クラスターはその答えからアイデンティティを得て、答えは明示されることで耐久性を得るのです。
次にパターン的拒否を名指す。 トピックに関係なく禁じ手となる声と構造の形は何か。使い回しのセットアップ語り、非公開テレメトリー、編集的な足場、根拠のない過激な意見など。コーパスの中に生き残るそれぞれのパターンが、声を薄めることになります。
興味深い拒否に気づく。 領域の内側にありながら、それでもカットされるトピック。それらこそが、荷重を担う趣味の判断です。他の書き手なら出荷するでしょう、しかしあなたはしない。あなたがしない理由が、クラスターの立場なのです。

Apple Ecosystem クラスターの全体像。Apple Intelligence サーフェスのための型付き App Intents、エージェントサーフェスのための MCP サーバー、両者の間のルーティングという問い、アプリ内・端末上の LLM 機能のための Foundation Models、ランタイムとツーリング LLM の区別、3 つのサーフェスの総合、Single Source of Truth パターン、Xcode 連携のための 2 つの MCP サーバー、Apple 開発のためのフック、Live Activities、watchOS ランタイム契約、SwiftUI の内部構造、RealityKit の空間的メンタルモデル、SwiftData のスキーマ規律、Liquid Glass のパターン、マルチプラットフォーム出荷。ハブは Apple Ecosystem シリーズにあります。AI エージェントを伴う iOS のより広い文脈については、iOS Agent Development ガイドを参照ください。

FAQ

「製品としての拒否」とはどういう意味ですか。

製品としての拒否とは、何かを成果物の外に置くという選択が、コンテンツが欠けているという決定ではなく、ポジショニングの決定であることを意味します。特定のトピックや特定の構造的パターンを拒否するブログクラスターは、テーマ内のすべてを出版するクラスターよりも、より識別可能な声を生み出します。このパターンは物理的な製品にも現れています。Steve Jobs の 1998 年の Apple 製品グリッドは、生き残ったものではなく、カットされたもので有名でした。同じ論理が書くことにも当てはまるのです。

これらの拒否は永続的なものですか。

永続的なものもあれば、そうでないものもあります。カテゴリー的拒否（クラウド LLM チュートリアル、採用関連技術）はクラスターのアイデンティティに結びついており、変わる可能性は低いものです。パターン的拒否（使い回しのセットアップ語り、編集的な足場）は実際の効力を持つ声のルールであり、これからも適用されます。興味深い拒否（サーバーサイド Swift、AppKit 専用）は、根底にあるアーキテクチャが変化したときに再評価されます。Swift バックエンドがエージェント的な Apple のワークフローにとって荷重を担う日が来れば、サーバーサイド Swift は枠を獲得するでしょう。リストはドグマではなく、現在の趣味そのものです。

そもそもなぜ拒否リストを公開するのですか。

リストを公開することは、3 つの読者に役立ちます。読者は記事をサンプリングするよりも早くクラスターの領域を学べます。未来の自分は、クラスターが拒否したと宣言した領域に流れ込んでいないかを照合するチェックポイントを得ます。他の書き手は、インターネットのこの一角における趣味によって形作られた書き方がどんなものかを知り、彼らが同じことをするための活性化エネルギーが下がります。コストは小さく（記事 1 本）、リフトは持続的なのです。

トピックを拒否すれば読者層が狭まりませんか。

はい、意図的にそうしています。クラスターは、生の読者数を最大化することではなく、特定の読者（エージェントを考えている iOS 開発者）と複利的に積み上がるよう設計されています。クラスターの領域外の記事は異なる読者を引き寄せるかもしれませんが、その読者たちは別のトピックのために来たので、いずれにせよ次の記事のために戻ってくることはありません。複利的な動きは、20 人の異なる読者にそれぞれ 1 回ずつ書くことではなく、同じ読者に 20 回連続して書くことなのです。

境界線上のトピックはどう扱いますか。

興味深い拒否セクションの基準を適用します。そのトピックはクラスターの立場を複利的に積み上げるか、それとも単に隣に並ぶだけか。複利的に積み上がる境界線上のトピックは書きます。複利的に積み上がらない境界線上のトピックはカットします、たとえトラフィックを引くとしても。決定は量についてではなく、時間を経たクラスターのまとまりについてです。複利こそが、保ち続ける基準なのです。

参考

クラスターの声のルール（使い回しのセットアップ語りなし、編集的な足場なし、証拠としての非公開テレメトリーなし）は、コーパス自体に表れています。クラスターの記事を 1 本読み、次にもう 1 本読めば、現れない繰り返しの形こそがルールの動作なのです。出版されたクラスターが、正典としての出典となります。