Lamy 2000でJetStreamの替え芯を使う方法

あとでちゃんと書く

 

メモ：

  1. Lamy2000という大変かっこいい4色ボールペンがある
  2. JetStreamという最高に書き心地の良いボールペンがある
  3. なんとLamyの替え芯をJetStreamのものにすることができ、かっこよく書きやすい最高の4色ボールペンが誕生する
  4. C4規格と呼ばれるもの
  5. 具体的な製品は下記2つがある。一般的なボールペンのサイズは0.7mm
    1. SXR-200-05(0.5mm用)
    2. SXR-200-07(0.7mm用)
  6. ところがLamy2000は黒・赤・青・緑の4色ボールペンだが、JetSteamには緑のラインナップがない
  7. なので、代用としてパイロットの アクロインキ BRFS-10F-Gが使われることが多い
  8. 近年JetStreamの会社である三菱鉛筆はLamyを買収したので、今後に期待したい
  9. あとJetStreamの替え芯はSXR-80シリーズという別サイズの商品があるので、間違えて買ってはいけない

Agentic RTB Framework(ARTF)とAd Content Protocol(AdCP)簡単まとめ

IAB Tech LabからARTF（Agentic RTB Framework）についての発表がありました。「AdCP（Ad Content Protocol）となにが違うの？どうなるの？」みたいなのが気になってる方は多いと思うので、軽くまとめてみました。

長いので三行まとめ

 

  1. ARTFはBit Requestに対してAI Agentで介在、AdCPは管理画面にAI Agentで介在させるための仕組み
  2. よってARTFでは主にSSP/RTB業者向き合い、AdCPでは広告代理店や広告主向き合いのプロダクトが産まれる
  3. 私見：AdCPのほうが成長の余地はずっとデカい。 ARTFはコストがかかりすぎで、既存プレイヤーがさらに強くなるだけになりそう。一方AdCPは各プラットフォーマーがOpenにしてくれるなら、いままで困難だった「プラットフォームまたぎでのあれやこれや」がAIを使ってできるようになる。

 

ARTFについて

ARTFはBit Requestに対してAI Agentで介在させるための仕組みです。
超ざっくりは下記のようなことができます。

 

  1. BidRequestに対していろんな情報を付与できるエージェントがたくさんいます
  2. オーケストレーター：「こんなビッドリクエスト来たけど、付与する情報を教えてくれ〜」とエージェントに一気に問い合わせ
  3. 各エージェントが付与すべき情報を返す
  4. オーケトレーテーター付与される情報をまとめてビッドリクエストを組み立て直し、オープンビッダーにわたす

付与する情報としては下記のようなものが想定されています。

  • ユーザセグメント
  • DealのOn/Off
  • Fraud/viewabilty/などの各種シグナル情報

 

私見としては「ほんとにやるの？」です。ビッドリクエストに介在となると全ビッドリクエストに比するサーバが必要なわけで、得られるメリットとコストが合うか大いに疑問です。すでに設備を保持している業者がより強くなるだけな気もしたりですが、RTBの時もCriteoみたいなプレイヤーが生まれたわけなので、いつもの「一瞬だけ開いたドア」なのかもです。

 

AdCPについて

AdCP(Ad Content Protocol)はざっくり各広告システムをAIで操作できるようにするための共通フォーマットです。ノリをわかってもらうためにAdCPを介してAIができるようになることを抜粋します。

planning関係

メディアプランニングの基礎情報を得るためのもの

  • get_products: 各プラットフォームで買える商品取得
  • list_creative_format: 各商品で使えるクリエイティブフォーマットの仕様取得
  • list_authorized_properties: 各メディアに対してどのプレイヤーが販売券を持っているかの情報（sellers.json的な立ち位置）

Campaing(media buy)関係

 

  • get_media_buy_delivery: media buyの情報取得
  • create_media_buy: media buyの作成
  • update_media_buy: media buyの情報更新

 

Creative関係

  • list_creatives: クリエイティブ取得
  • sync_creatives: クリエイティブ作成

Signal系

DMP/CDPを介して適切なオーディエンスセグメントを検索、取得、各プラットフォームにセットする仕組み

 

  • get_signals: 条件にあったオーディエンスセグメントを検索・取得
  • activate_signal: get_signalsなどで見つけたセグメントをDSPなりにセットする

perforance系

  • privide_performance_feedback: 各creative/media_buyの評価をこちらからプラットフォーム側に返す

雑感

 

ARTFは正直あんまりワクワク感がなかったです。AdCPも最初はmedia planing部分しかなかったので、「まだまだだな」というイメージでしたが、色々揃いつつあって面白くなってたなと感じました。


おわり

トラブル対応は全く無駄

ミスリードを誘うタイトルでお送りしております。

 

トラブル対応は全く無駄だと思う。もちろん「トラブルが起きてるんだからトラブル対応しなきゃに決まってるだろ」といった話ではない。

 

いきなり話が変わるが、私の奥さんは看護師で、結婚当初私が風邪を引くと優しくしてくれるのかな？と思ってたけど、毎回どえらく怒られていた。曰く

  1. 風邪は基本的に予防できる病気
  2. なのに風邪を引くのは怠慢な証拠
  3. 風邪を引くと会社休まないとだし、お金も時間も浪費するので本当に意味がない

いや、全くごもっともでぐうの音も出ない正論としかいいようがない。

 

さて翻って、みなさん自身がおもりするシステムの健康をちゃんと見てるだろうか？

上記の言葉をシステムトラブルに置き換えてみよう。

  1. トラブルは基本的には予防し得る
  2. なのにトラブルを起こしてしまうのは怠慢な証拠
  3. トラブルを起こしたら対応にかかるエンジニア工数や顧客対応の工数はドブに捨ててるのとほぼ同じで意味がない

 

また話は変わって、以前同僚からこんな話を聞いたことがある。

同僚「yamazさん、この会社に転職してから私は開発ばかりしてるのですが、いいんでしょうか？」

yamaz「？？？なんの話してるの？」

 

曰く、前職ではシステムがトラブル続きで開発リソースの4割位はトラブル対応と顧客への説明に費やしてたそうだ。それがあまりにも日常的すぎて、弊社に転職してから自身がトラブル対応をすることなく開発だけしてるのは、誰かが割りを食ってるのでは？という話だった。

 

この話を聞いて「トラブルは日常である」という発想から脱却してもらいたいという話をした。この「トラブルは日常である」という発想に立っている人は結構多いと思う。

 

「いやいや、風邪と違ってトラブルはあらゆる原因で起きるから予防は無理だよ」

 

まぁごもっとな意見だ。もちろんトラブルが起きる確率をゼロにはできないが、工学的に対応することでゼロに近づけることはできる。

 

 

ここで大事なのは複利効果だ。システムはハインリッヒの法則に従ってトラブルが起きるので、全くトラブルの再発防止をしないとシステムの複雑さに伴って複利効果でトラブルが多発し始める。これは逆を言えば小さなトラブルであってもそれを重大事故の予兆だとみなし、細かく適切な再発防止策を積み重ねることで、複利効果でもってシステムはどんどん堅牢になっていくことを意味する.

 

yamaz.hatenablog.com

 

トラブルの再発防止に対する考え方については上記エントリに譲るが、みなさんにおいてはトラブル対応に投入されるエンジニアリソースを始めとした各種リソースは、本来無駄なものだと心に刻み、ノートラブルで愛する人の元に怒られずに帰るようにしていただきたい。

 

あと私がトラブルに対して厳しい態度を取る理由もわかっていただけたかと思う（奥さん怖いよ）。

 

（おしまい）