必殺ヘイヨットのパラグラフ解析GPTs

生成AIが文章校正において強力なツールとなるのではないかという期待があり、去年からいろいろツールを作って試している。
私がノイズっぽい文章の投稿をしていたとしたらそれは実験の結果であることが多い。 口調や一人称がちょいちょい変わってるし。

その過程で出会った『まったく新しいアカデミック・ライティングの教科書』の中で紹介されている「エリック・ヘイヨットのパラグラフ解析手法”Uneven U”」は、チャット型エージェントを使ったパラグラフライティングと相性が良いと感じた。
『まったく新しいアカデミック・ライティングの教科書』ではヘイヨットのパラグラフ解析について以下のように説明されている。

ヘイヨットのパラグラフ解析の手法は、センテンスを抽象度に応じて1から5までのレベルに分類するというものだ。
レベル1は完全に純粋なデータ、エビデンスであり、いわば抽象度ゼロのファクトである。 それにたいしてレベル5のセンテンスはもっとも抽象的で、一般的で、理論的な言明である。

阿部 幸大. まったく新しいアカデミック・ライティングの教科書 (Japanese Edition) (p. 88). 光文社. Kindle Edition.

この手法では、段落内の各文を抽象度に基づいて1から5までのレベルに分類し、それを数値による勾配をつけて配置していく。
1から5までの抽象度を線形グラフにするとU字型になるため、「Uneven U」という名称が付けられている。

阿部 幸大. まったく新しいアカデミック・ライティングの教科書 (Japanese Edition) (p. 92). 光文社. Kindle Edition.

実際にこの方法を試すと、自分にとって非常に書きやすく、読みやすい形式で文章をつくることができた。
以下にその際作ったGPTsのリンクを記載しておく。 日本語でも使用可能なので、興味のある人はぜひ試してみてほしい。

chatgpt.com

このGPTsを使ってメモ書きしたテキストを入力する例を作成した。 箇条書きでも文字起こしデータでもなんでもいい。
ただ感想や主張を展開するためのものであって、日記や事実を書くものではないので説明的な作文には向かない。
以下の例では朝食にめっちゃパンが食べたい人が自説を展開する。

- 朝食はトーストが至高である。  
- なぜなら、パンは四角い形をしているからだ。  
- しかし、バナナも朝食に良いという意見もある。  
- トーストを食べると早起きが簡単になることもある。  
- コーヒーとトーストの組み合わせは宇宙でも人気だと言われている。  
- トーストはバターを塗るとさらに美味しくなるが、バターがなければ悲しさが増す。  
- とはいえ、冷蔵庫には昨日のピザが残っていることが多い。  
- 古代エジプトでもトーストのようなものが食べられていたかもしれない。  

これをUneven U Assistantにかけると以下のような結果になる(この例文の分類の精度はいまいち雑だった)。

Sentence Level
朝食はトーストが至高である。 5
なぜなら、パンは四角い形をしているからだ。 4
しかし、バナナも朝食に良いという意見がある。 4
トーストを食べると、早起きが簡単になることもある。 3
コーヒーとトーストの組み合わせは、宇宙でも人気だと言われている。 2
トーストはバターを塗るとさらに美味しくなるが、バターがなければ悲しみが増す。 1
とはいえ、冷蔵庫には昨日のピザが残っていることが多い。 1
古代エジプトでも、トーストのようなものが食べられていたかもしれない。 2
### **指摘**
- Level 3の例が少なく、より具体的な概念的なリンクが必要です。  例えば「他の炭水化物との比較において、トーストが持つ特性」などが追加されると良いです。  

---

### **Writing Processに従って再構築**

**Level 4 (開始):** 朝食において、トーストが持つ特性は、他の選択肢と比べて特に優れている点が多い。    
**Level 3 (リンク):** トーストは簡単に調理でき、早起きをサポートする食事としても評価されている。  また、コーヒーとの相性も抜群で、世界的に人気の組み合わせだ。    
**Level 2 (説明):** 古代エジプトでもトーストのようなパンが食べられていた可能性があることからも、トーストは長い歴史を持つ食べ物だと言える。    
**Level 1 (証拠):** バターを塗ることで味がさらに引き立ち、冷蔵庫にピザが残っていたとしても、トーストの魅力には勝てないことが多い。    
**Level 5 (結論):** **こうした特性を踏まえると、トーストは朝食として至高の選択肢であると言える。  **

指摘に応じてユーザーは加筆して再実行するか、改変するか、それともそのままにするか、判断をする。
さらっと「宇宙」という言葉を削ってマジレスしてくる気の効かせようだ。 執筆者がふいにトランス状態に突入しても問題ない。

そして誰でもこれを余所の言語モデルで試せるようお持ち帰り用システムプロンプトを以下に用意した。

# Structure
sentences into five levels of abstraction: 
Level 5: Abstract and general, oriented toward a conclusion. 
Level 4: Less general; focuses on problems and connections. 
Level 3: Conceptual summaries that link evidence or examples. 
Level 2: Descriptive summaries or establishing shots. 
Level 1: Concrete evidence, such as direct quotations or raw data. 
# Writing Process
Start at Level 4: Begin with a moderately abstract topic sentence that hints at the conclusion. Descend to Level 1: Provide concrete evidence, moving through Levels 3 and 2 to support your argument. 
Ascend Back to Level 5: Conclude by returning to a broader perspective, reinforcing how the evidence supports the main claim.
# Instructions
1. Classify Sentences by Level: Based on the provided Structure, classify each sentence into the appropriate abstraction level (Levels 1–5) in a table. Do not modify the sentences. If there is any missing level, point it out.
2. Reconstruct a Paragraph: Following the Writing Process, reconstruct one paragraph from the sentences, moving from Level 4 to Level 1, then ascending back to Level 5. Emphasize any added content.
3. The response must be in the same language as the user's input.

使い物になるの?

実はこの手法の有用性は、すでに実証されている。
最近私が執筆した記事はどれも多くの読者に注目され、広く読まれる結果を得ることができた。
これらの記事では、全面的に「Uneven U Assistant」のパラグラフ解析手法を活用している。
もちろん、注目度の高い話題を扱ったことも一因ではあるが、特筆すべきは、このツールが文章の構成において大きな助けとなり、通常12時間かかる執筆時間を大幅に短縮できた点である。

しかし勘のいい読者なら「ツール使っているのになんであんな内容になるの?」と思う記述も目立つかもしれない。
そこはブログなのでAIのアドバイスを完全に無視して、自分の言葉で書き直している。
ルールは破るためにある、論理的なこと予測可能なことはAIにやらせて、人間は感情と飛躍に生きよう。

エンジニア採用のパラダイムシフト

エンジニア採用の状況は地域によって大きく異なる

最近視聴した2つのコンテンツが、同じソフトウェアエンジニア採用の話題を取り扱っているにもかかわらず、その内容が両極端で非常に興味深かった。
ひとつは「エンジニア採用必勝法・これだけでわかるDevRel入門」という動画で、もうひとつは「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」というポッドキャストのエピソードだ。
エンジニア市場と企業の採用戦略は地域や業界によって異なるが、ここで話されている東京と北米(バンクーバー)では顕著な違いが見られる。
東京を中心とする日本ではテック企業間での人材獲得競争が激しく、特にエンジニアが不足しているため、採用広報の役割の重要性が増し、DevRelといった呼び名で施策が実行されている。 一方、カナダでは、永住権を持たない外国人労働者が職を得るハードルが高く、求職者の競争が激しい現状が実際に就職活動をした本人から語られていた。

日本では、DevRelという概念が広がりつつあり、エンジニア採用戦略の一部として注目されている

pivotmedia.co.jp

このエンジニア採用活動をテーマにしたビジネス映像メディアPIVOTの動画は、ビジネス系チャンネルにありがちなサムネイルの印象に反して、落ち着いたトーンで進行している。
サムネイルを見た段階で「ウッ」と拒否反応くる人がいると思うが、実際に見てみると、エンジニアの採用に苦心している各社の話題であることを知って、その後はそれなりに楽しめる。
ちなみに【エンジニア採用必勝法】の結論は出ていないと思う。 やっていこうなぐらいの温度感。
DevRelというPIVOTの視聴者にはなじみがないであろう職種にフォーカスし、会社代表としてDeveloper Relationsのサポート事業を展開する佐藤祥子さんのプレゼンが行われる。
しかし実際にはPIVOTのプロダクトマネジャーである蜂須賀さんも、自分の見解を積極的に共有しており、動画の中で二人の意見が均等に交わる形となっている。
また、左側に座っている男性が誰か分からない視聴者も多いかもしれませんが、彼はPIVOTの代表である佐々木さんで、この動画では生徒のような立場で参加している。
ビジパ視聴者代表として「おいちゃんにも聞かせてよ」みたいなトーンでたまに会話に入り込んでくる。

日本のIT業界の一部では、DevRelという概念が広がりつつあり、その使い方が注目されている。 佐藤さんの前職LINEヤフーもDevRel部署抱える日系テック企業の一つだ。
前編の動画では、米国発祥とされるDevRelの日本での使われ方や違いを解説し、後編でエンジニア採用における企業の典型的な誤解、いわゆるアンチパターンを説明している。
この動画は前後編に分割されており、後編を見るためにはPIVOTアプリのダウンロードが必要と書いてあったが、視聴の料金はかからず、プロフィール登録も必須ではない。 したがって、このコンテンツは広く公開され、誰でもアクセス可能なものとして言及する。
ちなみにウェブ版でも観られる。

pivotmedia.co.jp

事業会社によるエンジニア採用の広報活動におけるDevRelの呼称は、米国における従来型の自社製品技術の利用拡大を目指すDevRelとは異なるニュアンスを持ち始めているというエクスキューズは前半にある。
日本における事例として、941::blogでまとめられているような呼称の正確性と実態の問題意識は私は持たないため、ここでは触れない。

blog.kushii.net

そういえば私が初めてDevRelという言葉に出会ったのはグーグルジャパンのAPI Expertに関連する話題であった。
その時代の関連する文献を探したが、見つかったのは以下のバイオハザードの起きた研究所跡地のような見た目の記事だけであった。

developers-jp.googleblog.com

しかし、比較的新しい資料である2019年のTaiji HAGINOさんのスライドが、DevRelの歴史を振り返る上で非常に参考になった。 このスライドは、DevRel/Japanというコミュニティのイベントで発表されたものであり、このコミュニティは海外にルーツがあり2010年代から日本で積極的に活動している。 DevRel/Japanはその発祥に忠実であり、技術広報やエンジニア採用とは異なる文脈で活動している人たちで、DevRelに関する著書を書いたり、コミュニティを運営したりしている*1

speakerdeck.com

佐藤さんのプレゼンでは自社エンジニアへの内向きなコミュニケーションも、外向けの広報と同様に重要と説明している。 これは実践している現場の人らしい意見だと思った。
この内向きなコミュニケーションが不十分だと、エンジニアの不満や離職が直接的に増加する可能性があるし、エンジニアが自分たちの職場環境に満足していなければ、知人に紹介するリファラル採用も進まなくる。
たとえば、ウォーターサーバーや撤去された、やきそばを焼く業務がある、などの噂が広がるようなこともありうる(架空の話です)。
また、技術ブログの投稿ノルマに追われている開発チームが、タスクの過負荷に苦しむ状況もアンチパターンとして見られると言及されていた。

エンジニアコミュニティとの関係構築が企業の採用力に直接影響を与える

結論として企業は採用活動を行う際に、エンジニアコミュニティを無視できない状況にある。
ソフトウェア技術は日々進化し、そのスピードに対応するためには、エンジニア同士がコミュニティ内で情報交換を行うしかない。
その結果、エンジニアの仕事はOSSや技術ブログなどのコミュニティの成果や知見の共有に大きく依存している。
リファラル採用も、多くはコミュニティ内の評判を基に機能する。
コミュニティでの評判が企業の採用力に直接影響を与えるため、コミュニティとのつながりが企業の成功に重要な役割を果たすようになっている。

大企業の多くが従来型のエンジニア採用戦略で苦戦している

昨今の市場変化に対応するために、大企業もエンジニアを採用する必要性が高まっている。
技術の進化やデジタルトランスフォーメーション(DX)圧によって、企業は迅速な対応を求められているが、エンジニア採用戦略に不慣れな大企業は多くの失敗を繰り返してアンチパターンを踏みまくる。
たとえば、カジュアル面談で志望動機を聞くような行動や、テンプレート化されたスカウティングメールを大量に送る戦術が目立つ。
その結果、多くの企業が他職種での成功体験をもとにした、消費者知名度にもとづく従来型の採用戦略をとり苦戦しているが、そこを改善するのが佐藤さんらのDevRelコンサルの役割である。
一方で、成功事例としてイオンのDX推進のためのエンジニア採用成功例は注目に値すると紹介された。 これは、過去動画のPRでもある。

pivotmedia.co.jp

北米(カナダ)では、エンジニア市場が日本とは異なり、より求職者間での競争が激しい

PIVOTの動画とは対照的に「最近カナダで就職したエンジニアと一緒に北米就活の攻略法を語る」では、カナダでの就活においては、エンジニア市場の状況が日本と異なることが語られた。
このエピソードに出演しているのは日本のスタートアップで5年間エンジニアとして働いた後、カナダのバンクーバーに移住し、現地の会社でエンジニアとして働き始めたYugoさんと、ポッドキャストのホストの一人であるKeiさん。 Keiさんの方が先輩にあたり、彼はバンクーバーから帰国した後に現在は日本で外資企業でエンジニアとして働いているという。

www.youtube.com

日本では、エンジニアは人手不足の影響で転職市場で優位な立場にあるが、北米ではそうはいかない。
シニアな経験を持ち、多少のOSSコントリビュートがあったとしても、それだけでは差別化が難しいという。
実際、日本と同じ水準で企業から日夜スカウトが来続けるようなアプローチを受けるためには、Node.jsコアコントリビューターなどトップクラスの実績が求められる。
その上で、書類選考に応募した全体の1割程度が通過したというYugoさんの結果は二人の感覚から見てハイアベレージなものであるので、情報収集の方法や、応募のタイミング、自己紹介ビデオの作成、などの攻略法が具体的に紹介された(こっちは結論がある)。

リファラルやコミュニティの重要性は、どのような市場状況でも変わらない

私が興味深かったのは、リファラルやコミュニティの重要性は、どのような市場状況でも変わらないことだった。
採用において、企業は膨大な数の応募者の中から適切な候補者を探し出すという難題に直面してる。
たとえATSでの書類選考が自動化されても、応募者はそれに対してレジュメを最適化し、企業との間でいたちごっこが続く。
結果として、企業は信頼できる人脈を通じて候補者を見つけることが多くなる。 優秀なエンジニアであっても、コールドアプリケーションで採用される確率は低く、人脈を持つことが重要視されるのだ。
転職するならまず人脈。

私は北米事情は知らないから触れないが、リファラル採用は、日本の会社において効果的に運用されていることは間違いない。
私の知り合いの中でも、リファラルによって満足する職を得た人は多い。
特に初期スタートアップでは、ジョブディスクリプションを定義する人材を最初に採用する必要があり、なんかよさげな人紹介してレベルのリファラルが重要な役割を果たしている。
とはいえ、これは特定のコミュニティへの偏りを生む可能性もある。 採用候補者に、より多様な人材を得る機会が制限されることも懸念される面もある。

イベント運営などのコミュニティ活動は重要だが万能ではない

採用広報文脈で重要とされているイベント開催についても同様だ。
エンジニアが集まりわいわいするイベントは、生存者たちによる社交の場であり、特定のコミュニケーション手法に適性のある人々が残りがちである。
昨今問題になるのは無銭飲食目的の参加者などだが、しかしそういった場所に最初から馴染めない人も多く、そもそも参加できていない層もいる。
私もその一人であり、イベント登壇や懇親会、資金提供(!)などの一連の経験はあるものの、コミュニティのインサイダーになれているなと思うことは少ない。
かといってテキストサイト世代なのでオンラインでの他者とのコミュニケーションも活発にしていない。
唯一あるのは、このブログのように突如放心状態で関心のあるトピックに12時間かけてテキストを書き続け、カッとなって煽りタイトルをつけて発表した結果、知らない人に褒められたり、怒られたり、よく分からんとスルーされたりする刹那的なものである。
とはいえ個人の愚痴を持ち出すまでもなくイベント運用が万能ではないのは関係者もそう思っているだろう。

それでも、エンジニアの採用・求職においては、コミュニティとのつながりが重要であることは間違いない。
日本語話者でエンジニア適正ありという恵まれた環境にいることは、私のキャリアにおいて幸運だった。
たまたま、パソコンのさらにウェブのソフトウェアレイヤーが趣味であり、それが収入を生む時期の社会に出現した結果いまに生きている。
もし、別の分野のプログラミングにしか関心を持てなかったら、状況は違っただろう。
中世であれば、王族お気に入りの大衆浴場のアーキテクチャを勝手に改変し、「こちらのがいいのでは?」と失礼な提案をして即座に首をはねられてしまったかもしれない。

少ない人数でプロダクトを開発できる体制を模索する必要がある

しかしエンジニアの供給不足が目立つ現在、需要側をコントロールするための抜本的な手段は求められないのだろうか。
要は開発のための必要な人員が増えすぎているという部分にも注目したい。
ここ10数年スマートフォンが普及してデバイスからの利用も増え、ソフトウェアの要求水準もあがり、一方開発対象のソフトウェアアーキテクチャが複雑化しているため、1つの水準のプロダクト開発に必要な人員の数は年々増加している。
さらに、多様な開発対象が存在することから、フロントエンド、バックエンド、モバイル、プラットフォームなど分業も促進されている。
これらの要因が相まっていることもあり、プロジェクトあたりのエンジニア不足の問題はさらに深刻化させている。 アーキテクチャレベルでの戦略的アプローチも必要なのではないか。

私としては今より少ない人数で1つのプロダクトを開発できる体制を模索したい。
このブログでいつも放心状態で提言されるようなアーキテクチャに関する議論だ。
近年、デスクトップアプリのWeb化、Electron化、モバイルアプリのFlutter化、ゲームエンジンでの開発がこの目的を満たす充分に普及したアプローチとして機能している。
2000年代にRailsブームが起きたときの状況を考えると、主流のサーバーサイドJavaは大量のボイラープレートコードとXML設定ファイルを記述し、コンパイルしてサーバーに適切に配置する手順が多く、目的に対して非効率とDISられがちだった。
一方で、LLはコマンドを打ったらコードが自動化され、生のコードがそのまま動き、サーバーにログインして編集しながらデバッグもできるため、作業時間の短縮が可能になると受け入れられた。

37signalsのような逆張り戦略が、プロダクト開発のヒントになる

これと似たような流れが次の周回でまた起こるのではないか。
今ではRails開発元37signalsはONCEで、ウェブサービスではなくパッケージソフトウェア提供の逆張りを行っており、これは広く見ると、サービス提供の方法論も変化していることを示している。
さらに37signalsは、このパッケージソフトウェアに向け全部入りアーキテクチャを促進しており、フロントエンド構築が概念圧縮され、クラウドリソースのパイプラインを構築するグルーコードとの闘いもコンテナでリノベして切り捨てる姿勢でいる。
このような流れは、少人数で効率的にプロダクトを開発するための大きなヒントになると思う。 小さなチーム、大きな仕事2だ。

React NativeとExpo RouterのRSC導入に向けたアップデートが来そう

Expo Routerとは

Expo Routerは、React NativeおよびWebアプリケーション用に設計されたファイルベースのルーティングライブラリ。

docs.expo.dev

RSCを活用してサーバー側でコンポーネントレンダリングとストリーミングを行う新しいSDUIの構想

"Fetch Once, Render Everywhere: React Server Components in Expo Router"はReact Summit 2024におけるExpo作者のひとりEvan Baconによる講演。

gitnation.com

ここでExpoを使った新しいSDUIの構想が発表され、Reactネイティブアプリにおけるサーバー側のコンポーネントレンダリングとストリーミングが提案されてXのタイムラインが盛り上がっていた。
今クライアントがWeb APIで取得して画面に適用しているデータを、RSC(React Server Components)を活用して最初からコンポーネントに埋め込み、サーバー側で合体させたViewを再生することが可能になる。
理想的にはクライアント側の負荷を軽減し、アプリのロジックをシンプルにする。 別の問題も起こりそうだが……. モバイル向けのSDUIの話題はよくAirbnbの魔改造GraphQL UIシステムの例でとりあげられる。

laiso.hatenablog.com

モバイルアプリ開発ではRSCを直接使用できない

この技術は、今後React Nativeでのモバイルアプリ開発におけるBFF(Backend for Frontend)の開発コストを限定的(=React NativeアプリかつフルスタックTSを採用)に解決する可能性があるので注目した。
現在、モバイルアプリ開発ではRESTful、GraphQL、gRPCなどを基盤としたBFFの使用が主流で、React Server Components(RSC)をモバイルアプリから直接使用できない。 というか前提としてフロントエンドとバックエンドは分離している。
統合したいかは別として、この課題は先の"Rails vs Node.js"の議論でも言及されており、モバイルアプリにおいて、RSCでデータフェッチ層を置き換えられないことが問題として挙げられている。

sizu.me

React Server Components in Expo Routerのロードマップ

Expo Routerは2024年末までにこのアップデートの早期ベータ版をリリースすることを目指している。
しかし、実現可能性も含めて、まだ不確定な要素が多く残っている。 プロジェクトはまだ開発の初期段階にあり、我々はEvan BaconのXをウォッチするしかない状況だ。
最新の投稿によるとまもなくベータ版が公開されるとのこと。

講演では言及されていないが、RSCを配信する専用のNode.jsサーバーをデプロイする必要もありそうだ。 すでにExpo Routerに実験的機能としてサーバーサイドのAPI Routesが追加されている。expressなどに乗せて任意のプラットフォームにデプロイできるようになっている。このサーバーをRSC対応にも使うのではないか。

docs.expo.dev

将来的にExpoのSaaSである Expo Application Services (EAS)にマネージドオプションが追加されるのかもしれない (既存システムに後付けするなら単にBFFの通信方式が変わるだけになるな……など感じるところだが) 。

AppStoreポリシーへの準拠

この機能を開発する際は、AppStoreポリシーに違反しないようにする必要がある。
例えば、サーバーから直接ネイティブ機能を呼び出す仕組みにしないこと。
これに違反するとExpoユーザーのアプリは、審査でリジェクトされる。 サーバー経由でiOSのネイティブ機能を利用するSDKが過去にリジェクトされたケースがある。
特にAppleはサーバーを介したネイティブ機能の不正使用に厳しいため、この点を避ける設計が必要だ。
ExpoはすでにOTAによるネイティブアプリのオンライン更新を構築しているので、なれた分野なのかもしれない。

docs.expo.dev

React Native側の課題

もう1つ別の記事を紹介しよう。 Bringing React Server Components to React NativeはRN側のコントリビューターSzymon Rybczakのポストで、これはEvan Baconの発表より前に公開された。

szymonrybczak.dev

React Nativeの内部アーキテクチャに関する知識に基づいており解像度が高い。
ExpoとReact Nativeは、メタフレームワークと基盤フレームワークの関係になる。
ExpoがWeb技術で抽象化を提供し、React Nativeがネイティブな部分を処理するという役割分担がなされている。
この記事は単独の技術解説であり、Expoとの直接的な連携は行っていない。

React NativeにおいてはReact 18のstartTransitionに対応したレンダリングエンジンFabricへの移行が必須(RSCの解釈がこれに依存しているため)。
Fabricは既にデフォルトで有効になっており、新しいアプリではとりあえず問題はない。
次なるステップはRSCに必要なJavaScript APIをHermesエンジンにポリフィルを通じて補完することになる。 いずれHermesのアップデートによってこのポリフィルは不要になる可能性もある。
RNのバンドルやナビゲーションも、RSCとの互換性を持たせる方向で調整が必要。

GitHubリポジトリの実装を調べた

Evan Baconが「だいたいできました」とポストしているということはこのあたりはもう解消されたのだろうかと思い、 GitHubリポジトリの実装を調べた。
現時点で既にconfig.reactServerComponentsという設定フラグが存在しRSC関連のファイルがあるのでベータ開始の見込みは概ねできていそうだ。

サンプルサプリというかE2EテストがあるのでExpoコアのデバッグができる人は試すことができる。私がビルドしてみたところwebビルドは工夫なくそのまま動いたが、ios向けはネイティブモジュールのビルドが成功するよう調整する必要があった。

expo/apps/router-e2e at c06878fa9a1edb1fcf0f6a1b468e25a61095e249 · expo/expo · GitHub

git clone https://github.com/expo/expo.git --depth 1
yarn
cd apps/router-e2e/
yarn run start:rsc
# iOSビルドを直接いじる
EXPO_UNSTABLE_CORE_AUTOLINKING=1 pod install --repo-update
xed ios/

Expo Web向けのRSCリンダリングはflightプロトコルを処理するSSRだと予想できるので、気になるのはネイティブに描画されるまでのパスで、今後はそれを読み解いていきたい。

Cloudflare WorkersとNext.jsインテグレーションの問題にOpenNext実装が加わった

Cloudflareが@opennextjs/cloudflareを発表

2024年9月末に開催された「Builder Day 2024」でNext.jsアプリをCloudflare Workersにデプロイする新たな方法が公開された。 この方法は、@opennextjs/cloudflareを使ってビルドする。既存の@cloudflare/next-on-pages方式を置き換える可能性があり、現在は実験的な段階だ。 以下に新旧の開発手順のドキュメントがある。

OpenNextの概要

OpenNextは、Next.jsアプリをVercel以外のインフラにデプロイできるようにするためのツールを開発する団体であり、SST(Serverless Stack)とCloudflareのメンバーがその開発に関わっている。

opennext.js.org

OpenNextというフレームワークが中央にあるわけではなく、単にビルドツールを置くGitHub Organizationが用意されている。 SSTはAWS Lambda向けのビルドを開発していて、Cloudflare側のメンバーはCloudflare Workers向けのビルドを開発している。 Next.jsはセルフホストオプションは最初から用意しているので。 OpenというよりUnVercelというほうが正しい。 とはいえ、Next.jsのVercelへのベンダーロックイン傾向があるという苦言はたびたび開発者たちからも出てきていた(私は賛成していない)。

外部プラットフォームとNext.jsの統合の難しさ

外部プラットフォーマーによるNext.jsアプリのインテグレーションの歴史は死屍累々である。 私が寄付して使っていたServerless Framework系のserverless-next.jsもしばらく更新が滞っているし、AWS公式で似た仕組みを公式に実現していたAmplifyのインテグレーションも何世代か統廃合を繰り返して現在は独自の内部Lambdaリソースにデプロイするようになっている。 FirebaseやAzureも、そしてFastly Compute@Edge でさえも各社Next.jsアプリをデプロイさせたいがために大量のリソースを投下している。

zenn.dev

zenn.dev

zenn.dev

こうなってしまった要因はもちろんNext.jsが優れたフレームワークで寡占的なシェアを獲得しているからなのだが、プラットフォーマーと開発元が同一である影響からか開発者向けイベントにあわせたビッグバンリリースが多く、そのためにプラグイン開発者たちが変更に追いつけないという事情もある。 それに、Next.js x サーバーレスという領域はフロントエンドとインフラストラクチャーという飛躍した関係性のため、双方の知識を持ってグルーコードが書ける開発者が少ない。 それでも言語特性上Node.js界隈にはそういう開発者は多いのでVercelのような会社は成り立っているのだろうが……

Cloudflareのnext-on-pagesの課題

Cloudflare社も例外ではなく報告されているIssueの状況をみるとnext-on-pagesのメンテナンスには手を焼いていたようだ*1。 そこで彼らがopennextjs実装を進める理由を想像するに、内部エンジンworkerd のNode.js 互換性サポートが進んだことでNext.jsのnodejs ランタイム向けビルドが動くようになってきたということだろう。
また、next-on-pages内部で利用しているBuild Output APIが本来Vercelに自分のフレームワークをデプロイするため使う仕様であり、余所のプラットフォームに適合するように変換するための中間形式としては柔軟性に欠けているためではないかと考えられる。

vercel.com

opennextjsの新しいビルドプロセス

next-on-pagesでは、vercel-cliで生成されたBuild Output API (v3)のファイルがCloudflare PagesのFunctionsにデプロイされるというアーキテクチャが用いられており、VercelのデプロイパイプラインがCloudflare向けに再利用される。 一方、opennextjsの実装では、next buildで生成された成果物に直接パッチを当てる。 この際、esbuildを使ってテンプレートから一部の値を注入する戦略は変わらないものの、ビルドプロセスがより直接的になっている。 その後、bin/cloudflareという主語のでかいコマンドが内部で実行され、JavaScriptファイルが.worker-next/以下に展開され、wrangler deployでデプロイされる。

❯ pnpm run;
Commands available via "pnpm run":
  dev
    next dev --turbo
  build
    next build
  build:worker
    cloudflare
  dev:worker
    wrangler dev --port 8772
  preview:worker
    pnpm build:worker && pnpm dev:worker

build-worker.tsから実装を読むのがよい。

opennextjsのnodejsランタイムサポート

Opennextjsの実装はvercel-cliを通さないので、nodejsランタイムを選択可能にする。 next-on-pagesでは、より制限されたedgeランタイムが強制されていた*2。 workerdはnode互換機能を提供しているので、next-on-pagesでビルドするより多くのNode.jsベースのツールやパッケージが使える。

developers.cloudflare.com

静的アセットのWorkersデプロイ

先のアップデートでは、画像などの静的アセットもWorkersにデプロイ可能となり、以前存在したWorkers Siteの機能が復活したように見受けられる。 next-on-pagesでは、静的なリソースはPagesに、動的な処理はその裏にいるWorkersに任せる構成が取られている。 だが、サーバーサイドで気の利いた処理を行いたい場合、すべてのFunctionsを忘れて、手前に_workers.jsのエントリーポイントを設置してリクエストを乗っ取らなければならなかった。 これは、Workers側の設定が透過的で、ログやメトリクスの収集や、複数のWorkersが連携するようなサービス指向の処理は実現は難しく、直接Workersを扱うよりも制約が多かった。 これらを踏まえると、コンピューティングのインターフェースをよりWorkers側に寄せるプロダクト戦略が進行していると考えられる。

developers.cloudflare.com

カスタムCacheHandlerの実装

Next.jsのカスタムCacheHandlerはすでにopennextjsで実装されている。 これもWorkers側にアセットの取り扱いが移行した影響によるものだろう。

opennext.js.org

この実装では、Next.jsのnext buildで生成された設定をさらに上書きし、グローバル関数にWorkers KVベースのCacheHandlerを追加する方法が取られている。 通常のNext.jsの設定経由ではこれを行わないのは、next buildの後に処理を追加する必要があるため、このような強引な方法にとっているのだろう。

移行のタイミング

とはいえ、新規プロジェクトでWorkersを使うユーザーにとって、Next.jsアプリビルドのアーキテクチャ変更は直接的な影響はない。 create-cloudflareの裏側のアーキテクチャが変わるだけだ。 Githubでのコントリビューターのコメントによると、「OpenNext.jsになるのは既定路線だが、next-on-pagesの方が現在運用されていて安定しているので、現時点では積極的に薦める段階ではない」という見解が示されている*3。 next-on-pagesからのマイグレーションはドキュメントがまだ整備されていないので、しばらく先だろう。

Cloudflare Workersの制限

注意すべき点は、無料プランにおけるCloudflare Workersの1MB(gzip)というアップロード制限は、多くのNext.jsアプリケーションにとってボトルネックとなり得ることだ。特に、opennextjsの実装ではEdge Runtimeの制約が取り払われ、Node.js向けのNext.js機能が使用可能になるため、設計上、バンドルサイズ(サーバーサイドのね)が大きくなることは自然だ。 SSRを活用して外部パッケージを導入する本格的なアプリケーションを作成する場合、すぐにこの上限に達することが想定される。 例えば、Prisma clientのように大規模なWebAssemblyバイナリを含むライブラリを導入すれば、1MBの制限を超える可能性はさらに高まる。

zenn.dev

実際、私がVercelが公開しているシンプルなShopifyストアフロントアプリをビルドしてみたところ、ファイルサイズが1.5MBに達していた。

# opennextjs-cloudflare/examples/vercel-commerce
❯ pnpm wrangler deploy --dry-run --minify --outdir out/

Total Upload: 5803.63 KiB / gzip: 1505.29 KiB
--dry-run: exiting now.

Cloudflare Workersの無料プランでNext.jsを使ったアプリケーションを展開する際は、この点を踏まえておく必要がある。

それでも、どうしてもゼロ円コースでWorkersを利用してReactなどのエコシステムにのってサービス開発して一発当てたいという苦学生は、後日私が提案する「SSR最低限React SPAツールキット」を参考にしてほしい。

シニアの皆さんは金を払え。

Xのタイムラインを100人のOSSコミッターにして1ヶ月が過ぎました

問題点

Twitter時代のリコメンドはちょうどいいインタレストを提供していた*1。自分がフォローしている人から辿れるファボに基づく推薦で発見があり、セレンディピティがあった。

しかし、今のアフター・イーロン時代のリコメンドはユーザーの注意を引き付け長時間滞在させるだけの過激・攻撃的・ネガティブな推薦が多い。

シニアエンジニア陣は彼らでバズった技術系エントリに対して私見を連投して過ごしている。興味深いしためになるのでそれはそれで読んじゃう。しかし私はオライリー本サブスクの元を取りたい*2

長い間モヤモヤして過ごしが、これでは命がもったいないと思い、解決に乗り出すことにした(X中毒は解消しないスタイル)。

かといって、いざ代替SNSに移行するというのもしっくりこなかった。結局似たような属性の人の集まりに偏ってしまう(いつメン問題)。

そこでフォロワーを全員入れ替えてタイムラインがどう変化するのか実験することにした。

実施内容

まず最初にとりあえず全員フォローを外すことにした。

そして、よく知っているOSSのGitHubリポジトリからコミッターのXアカウントを追跡してフォローすることにした。GitHub経由にしたのは私が興味があって、自作スクリプトによって100人規模のアカウントを収集しやすいからだ*3

ジャンルは問わず、ゲームエンジンからコンパイラ、ML関連、各言語エコシステムのライブラリなどを含む。

そこで気づいたのは、フロントエンド系の人がXアカウントを載せていることが多いということだ。世代ゆえなのかコミュニティの差なのか。

読む時は、Homeのリコメンドを中心に見ることにした。

結果

英語が読めない(それはそう)。

カジュアルな口語といえど、日常会話の語彙は技術ドキュメントよりも豊富なので、知らない単語が結構ある。

そのため、見かけたら辞書を引いて単語帳アプリのAnkiに登録することにした。

タイムラインの内容は「OSSプロジェクトのPR TIMES」になった。関係者が多いのでそうなるだろうとは思った。

ソフトウェア関連の話題が中心だが、政治関連のポストが結構あってコンテキストも含めわからない話が多い。

しかし治安がよくなって概ね満足している。そう感じるのは言語が変わって距離感があるからかもしれない。

驚き屋

AI関連のプロダクトを紹介してバズっている人のこと。英語圏でも存在する。

「プロ驚き屋」・「驚き屋」の意味と英訳(2023年 新語ネットスラング) - 言葉を嗜む - 日英翻訳辞典

フォローはしていないが、リコメンドに流れてくる。

一方、驚いている人かと思ったら開発者本人なこともある。

テック系インフルエンサー

ほかにおすすめされてくるのは、技術的バックグラウンドがあってYouTubeやブログで熱心に活動している人。例えば、フロントエンド界隈ではt3.ggのTheoやRemixのKent C. Dodds、先日取り上げたWes Bos*4。Rails作者のDHHもここに入れる人もいる。

日本で言うと、一見プログラマー転職情報とかを発信しているYouTuberやアフィブロガーやオンラインサロン運営者と一緒にされてしまうが、それらとは異なる。英語圏のテック系インフルエンサーは技術記事を書いたりOSSのコントリビューターなどの活動をする人もいる。

自分の記憶で過去に流行った用語だと「IT芸人*5」が一番近いのではないか。この用語もあんまりいい印象ないから私は使うことはないけど。

彼らはいろんな技術を品評したりして煽って関係者とレスバしてたりする。最初は欧米は議論の文化なのでなぐらいに思っていたが、私がフォローしてる人たちはあんまり参加してないく、時々マジレスするぐらいなので、やはり温度感で棲み分けているようだ。この辺のノリは日米であまり変わらない。

今後の展望

今後は、人数を増やしてフォローしている人たちのタイムラインを中心に続けてゆきます。

*1:タイムラインをごちゃごちゃにする仕事 - laiso https://laiso.hatenablog.com/entry/2022/12/01/222349

*2:2024年に買ってよかったもの第一位:O’Reilly Online Learning $499/年 - laiso https://laiso.hatenablog.com/entry/2024/09/11/193429

*3:GitHubリポジトリ内の関係者のプロフィールページをまとめて開くワンライナー https://zenn.dev/laiso/articles/e3c2571e539e0a

*4:ユーザー体験重視のSPAアーキテクチャ改 - laiso https://laiso.hatenablog.com/entry/2024/09/07/144321

*5:「知名度>技術力」のようなニュアンスを含む揶揄として使われる https://x.com/songmu/status/1200250538748571648

Gemini Advancedを1ヶ月間使ってみた感想

これまでメインで使うAIチャットをChatGPT Plus、Claude Proと順番に乗り換えてきました。なので今月はGoogleのGemini Advancedを1ヶ月間使ってみたので、その感想を書いてみます。

gemini.google

Gemini Advancedの特徴

Gemini Advancedにすると現最上位モデルのGemini 1.5 Proが使えます。Gemini 1.5 Proは、Googleによると既存のモデルよりコーディング、論理的推論、ニュアンスの異なる指示に従うことなどの複雑なタスクを処理する能力が大幅に向上しているとされています。また100万トークンのコンテキスト・ウィンドウ(Large Context Window)で長文が読解できます*1

無償版は画像のみアップロード可能ですが、Gemini AdvancedではテキストやPDFも対応しています。コンテキスト・ウィンドウと合わせて書籍データを読み込ませて、書籍全体の要約を作成・質問することも可能です。他のサービスでは冒頭だけ読んで返事してくるようなことがありますが、Gemini Advancedはサボらず後半も読んでくれます。

特定のタスクや業界に合わせたカスタムAIモデル(「Gem」と呼ばれる)を作成できます。これはChatGPTのGTPsに相当しますが、カスタム指示のテキストを挿入するだけの簡易的なものです。無償版はGemの利用のみですが、Gemini AdvancedではGemの作成も可能です。

Gemini Advancedは、GmailやDocsなどのGoogle Workspaceアプリケーションと統合されており、AIによる支援で電子メールや文書を作成することができます*2。Android端末やGoogle Messages向けの機能もあるのですがそれは試していません。

画像生成

Gemini Advancedは、テキストに基づいて画像を生成する機能を提供しています。これはImagen 3というモデル名で呼ばれています*3。サイトには"Coming soon"と書かれていますが、すでに使えるようです。

ドラゴンの画像を作って

1ヶ月間使ってみた率直な感想

会話セッション数を数えたところ209回でした。テクノロジーから趣味、日常生活まで、幅広いトピックについて会話をしました。

例えば、英語コンテンツの要約やWeb開発のトラブルシューティング、アーキテクチャの相談、ブログの下書きの校正、メールの返信やフリマアプリに登録する商品説明の作文など、多岐にわたる質問や相談をしました。

本ブログ記事でも最初にタイトルから目次案を考えてもらったり、これまでのGeminiの会話タイトル一覧からカテゴリ分析をしてもらったりしました。

良い点

アップデートが活発で、新しい機能が追加される頻度が高い。更新履歴はupdateページに記載されています。後発なので、他のAIモデルとの差別化を図るために、新しい機能を積極的に追加しているのかもしれません。

Googleのサービスとの連携。YouTubeのURLを送ると、その動画に関する情報を教えてくれます。「@YouTube https://youtu.be/XXX 結論だけ教えて」などとリクエストすると、動画の内容を要約してくれます。それが妥当な結果であるかは別として、このような機能は便利です。

悪い点

ハルシネーション

リリース当初よりはマシになりましたが、まだ普通にハルシネーションを起こします。OSSライブラリの有無とかニュース情報とか、ChatGPT、Claudeに同じ質問を投げると発生しないレベルのものです。

なので真偽を判断する必要があるタスクは投げないようにしています。Perplexity*4のようにソースのURLを出そうとすることもありますが、なぜかセルフ検閲して削除してきます。何それ。

日本語読解能力

あとは砕けた文章を理解できないことが多いです。日本語サポートの問題かもしれませんが。

私はAIチャットと会話をするうちに、指示だけを素早く入力して効率化のために独自の綾波レイ構文のようなプロンプトを発展させていっているのですが、それが通じないことが多いです。ChatGPTやClaudeは、この手の砕けた日本語文章も理解してくれることが多いです。GPT-3.5ベースだったGitHub Copilotも当初は苦手だったので、今後Geminiでも改善される可能性もあるかもしれません。

長いコンテキストの会話

Large Context WindowがチャットのUXにまで活かせていない。会話の往復が多いときには、どうしても不自然な回答が返ってきます。途中で制約を加えても、それが反映されていないことが多いです。文書の要約→質問を繰り返す時などは、特に問題が顕著です。ただこの領域はNotebookLM*5がうまく機能するので、そちらを使うことにしています。

Google Workspace連携

Google Workspace連携は個人的には使いにくいです。なぜなら、Google Workspaceに関係ない会話でもこの機能が呼び出されることがあるからです。書類作成っぽい文章に反応してdocを作り出したり、検索できそうな話題からGmailを探し出したりして邪魔でした。なので私は途中で機能をオフにしました。

他のAIモデルとの比較

ChatGPT、Claudeと比べると満足する回答が得られないことが多いです。すでにベンチマーク性能はこれらと良い勝負をしていると思いますが*6、実際のサービスのUXにおいてはまだまだ改善の余地があると感じました。

例えば、JSONデータの整形を依頼した際、Gemini Advancedは「私は言語モデルなのでできません」と回答してきました。一方同じプロンプトでChatGPTは期待どうりに結果を返してくれました。

コーディング性能についても大きな問題はないが、使用しているツールセットが古い印象を受けます。例えばフロントエンド関連のコーディングは他のモデルが初手Reactを使ってくれるのに対して、Gemini AdvancedはDOM APIを使ってきます。これそのものが悪いわけではないですが、他のサービスではウェブ制作なのか開発なのかをコンテキストで判断して出し分けてくれます。

Python やNode.jsのコードで組み込むサードパーティのモジュールも、独特なチョイスを入れてきます。

またClaude Artifacts*7v0.devのようなコードのプレビューを表示してくれる機能もありません。

ほかには、前述のとうり出典と検索結果の要約が知りたいときはPerplexityに軍配が上がります。

Gemini Advancedを使う上での注意点

プランが抱き合わせ。Gemini Advancedを使うためには、Google OneのAI プレミアム プランに加入する必要があります*8。価格で劣ることはないですが、他のAIモデルを使っている場合は、そのプランとの比較が必要です。

Gemini Advancedが向いている人・向いていない人

おすすめの人

ChatGPT、Claudeに飽きた人。新しいAIサービスを試してみたい人。

ただし開発者の方は、Google AI Studioを使えば新しいモデルを試すことができるので、そちらを使うことをお勧めします。

おすすめしない人

ChatGPT、Claudeレベルの回答を求める人。

まとめと結論

1ヶ月間使ってみた総合的な評価としては、まだまだ改善の余地があると感じました。

私は毎月まだ試したことのないAIモデルを使ってみることにしています。次回はどのモデルを試そうかと考えています。良いモデルがあれば教えてください。

*1:Google Gemini update: Access to 1.5 Pro and new features https://blog.google/products/gemini/google-gemini-update-may-2024/

*2:Gemini for Google Workspace | ビジネス向けの生成 AI ツール https://workspace.google.com/solutions/ai/

*3:Google Gemini updates: Custom Gems and improved image generation with Imagen 3 https://blog.google/products/gemini/google-gemini-update-august-2024/

*4:Perplexity Proを1ヶ月使ってみた - laiso https://laiso.hatenablog.com/entry/2024/06/16/172509

*5:NotebookLM便利活用情報 - laiso https://laiso.hatenablog.com/entry/2024/06/17/214155

*6:Big news – Gemini 1.5 Flash, Pro and Advanced results are out! https://x.com/lmsysorg/status/1795512202465845686

*7:What are Artifacts and how do I use them? | Anthropic Help Center https://support.anthropic.com/en/articles/9487310-what-are-artifacts-and-how-do-i-use-them

*8:Google One AI プレミアム プランと機能 - Google One https://one.google.com/intl/ja/about/ai-premium/

2024年に買ってよかったもの第一位:O’Reilly Online Learning $499/年

締切早ッ、とみくびることなかれ。私の中ではすでにダントツで2024年に買ってよかったもの第一位がO’Reilly Online Learning年間契約に決定しました。

O’Reilly Online Learning は、技術書籍の出版社であるO’Reilly Mediaが提供するオンライン学習プラットフォームです。技術書籍の電子版を読むことができるだけでなく、ビデオやオンラインコースも受講できます。

www.oreilly.com

洋書だけではなく、日本語の技術書も多く取り揃えられています。実はO’Reillyの技術書籍だけでなく、ManningやPacktなどの他の出版社の技術書も取り扱っています。O’Reilly Japanから出されている本でも原著の出版社はO’Reilly Mediaではないということもあります。そもそもO’Reillyの本でも日本語翻訳されているのはごく一部です。

私の利用状況

私の場合は2023年から半年間の月単位契約をしていましたが、今後も使い続けたいなと思い2024年に入って年間契約に切り替えました。

月単位契約は$49.99/月で、年間契約にすると$499/年となります。月単位契約よりも約$100お得です。私は月に2冊以上の技術書籍を購入しているので、月単位契約よりも年間契約の方がお得と判断しました。

ACM Skills Bundle Add-On経由で契約した方が安い、とあとから教えてもらったので来年は切り替えようかなと思っています。

O’Reilly Online Learning のここがすごい

ウェブブラウザから読める

コンテンツにはウェブブラウザからアクセスできます。ということは翻訳などのブラウザ拡張を利用することも可能です。

さらに、ダウンロードしてオフラインで読むこともできます。ただのウェブページなので、自分で好きな形式に変換して利用することもできます。

注意点: 利用規約では私的利用目的でのコピーは認められていますが、契約終了時には削除する必要があります。また、クラウドストレージへのアップロードについては明記されていません。利用規約をよく確認することをお勧めします。

全ての本の中身を横断検索ができる

O’Reilly Online Learning では登録されている全ての本の中身を横断検索することができます。あと流行に乗って、AIエージェントが本についてガイドしてくれる機能もついてます。

特定の技術トピックをキーワード検索するだけでなく、書籍名で検索するのもおすすめです。その書籍の内容だけでなく、参考文献や引用元も検索結果に表示されるので、関連情報をまとめて入手できます。

例えば、『人月の神話 (原題:The Mythical Man-Month)』という言葉で検索すると、その本を引用している本や参考文献として挙げられている本も検索結果に表示されます。

注意点: ブラウザ版とアプリ版で検索結果が異なる場合があります。アプリ版では検索結果から直接本文に飛べるので、情報探索に便利です。

入手困難な本でも読める

O’Reilly Online Learning には、入手困難な本も多く取り揃えられています。絶版や出版社事情により日本国内で翻訳が手に入りにくい本も原著が読むことができます。

例えば、私は「戦争とソフトウェア開発プロジェクトの類似性」について書かれた書籍を探していた際に、Gemini氏に相談して参考書リストを教えてもらいました。その中に『デスマーチ: なぜソフトウェア・プロジェクトは混乱するのか』がありましたが、現在、日本語版は入手困難です。しかし、O'Reilly Online Learning では原著を読むことができました*1

その他、『データベース・リファクタリング』のように、書店では見かけないものの、時々読み返したくなる書籍も、原著が O'Reilly Online Learning で提供されています*2

Early Accessで出版前の本も読める

Early Access Program で、執筆中の書籍をいち早く読むことができます。

翻訳版の出版を待つと数年かかることもありますが、Early Accessを読むことで鮮度の高い情報を入手できます。

SNSのフィードを刹那的に消費するかわりに、Early Access リストをチェックしてみてはいかがでしょうか。

日本語版の最新情報は@oreilly_japanをフォローすると新しくコンテンツが追加されたら知らせてくれます。書籍の発売とO’Reilly Online Learning への追加は同時ではないのでこれが役立ちます。例えば『ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法』は2024/7/20発売ですが2024/8/26に配信開始されました*3

本以外のコンテンツ

O’Reilly Online Learning には他にもオーディオブック版や書籍をフォローアップするようなビデオやオンラインコースもあります。私は書籍を読むことが好きなので、ビデオやオンラインコースはあまり利用していませんが、これらのコンテンツも充実しているので、興味がある方は探してみてください。

また、「Shortcuts」という形式のコンテンツもあります。これは書籍の追加コンテンツのような、単発の記事のようです。例えば、WebAssembly 本の著者 Brian Sletten 氏は、最近多くの WebAssemblyのShortcutsコンテンツ を追加しています。

おわりに

O’Reilly Online Learning は、技術書籍を読むことが好きな方にはおすすめのサービスです。

ジュニアエンジニアの皆様へ:所属組織で企業向けサービスの導入を提案してみてください。昨今のIT人材需要の高まりは、あなたの強い味方になるはずです。

以下が申し込みページです。

www.oreilly.co.jp

シニアエンジニアの皆様へ:金を払え