  |
はてなキーワード:ダッシュボードとは
https://anond.hatelabo.jp/20251007140921
急にハワイ旅行記がバズってたので
我々もオフシーズンの5月くらいにハワイに行ってきたので便乗したい
初ハワイ。ヒルトンタイムシェア説明会の無料宿泊に釣られて行くことになった。
お互いどちらかというとインドア派だと思われる。
食の好みは私はカロリーで妻はヘルシーだ。
なお、行く前にYoutube、特にちゃんすうの動画を見まくって予習してた
細かすぎて長いがその分参考になる
ただ3人川の字は無理なので、私は普通に座って寝ることに。なんとか全員多少寝ることはできた。
行きの6時間、なかなか限界を感じ、帰りの8時間しかもそこから成田の帰路車運転するの？死ぬのでは？となり
10万くらい追い銭し、プレミアムエコノミーにアップグレードした（オークション形式）
が、プレエコも前の席が全力で倒してくるタイプだったので結局それなりに厳しかったんだよな〜〜〜
前席ガチャに負けたので、広く結構快適な席ではあったがコスパを考えると…
あと、帰路なのでホノルル空港でANAのラウンジを使えたのだが
まぁご飯とかも、普通に空港のフードコートで食べたほうが満足感あると思う
子のためキッズスペースを使えたのはよかった
まだあった。ANA便はワイキキとアラモアナを往復するシャトルバスと、ワイキキ内のラウンジが使える。これがよかった。
アラモアナはピンクトロリーも結構混んでたりするが、こっちは空いていて乗りやすい。またキャリーバッグでも乗れる。
ワイキキのラウンジも良く、今や1本400円くらいしてしまうジュースの缶が飲めるのがありがたい。
場所も良く、トイレも広くてきれい。対象者も少なくJCBラウンジとかより空いてるとあって、かなり使わせてもらった。
これはANA便で良かったところだったな。
今にして思うと初手でアイコロかよ！？って思う。なかなかリピーター向けの所だった感。
安く抑えたいはずだったのに、展望に抗えず高層階を取ったので結局高くはついた。
が、その価値は十分にある。43階！全面のダイヤモンドヘッドビュー！最高！！！
色々あり、宿泊場所としてみると星を減らそうかと思ったが、展望が最高すぎるので星5つです。
他
ハワイの治安はヤバいとは聞いていたが、幸い今回特に危ない目に会うことはなかった
正直体感治安では新宿とかの方がよっぽどヤバいのではと思うが、まぁ危険の最大レベルが違うよな
もともとサンドヴィラってホテルだったのが、ここ数年でリノベしたらしい。
やはり一泊くらいオシャレなホテルで泊まりたかったので、無理やりねじ込んだ。
1台のベッドで川の字で寝たかったので、プールサイドの広い部屋にした。そのためちょっと高い。
ここはすごく良かった。スタッフがみんな明るく感じが良い。良い意味で若々しくエネルギーをもらった。
内装もめっちゃオシャレだし、まだ新しい。レコードとか初めて触ったんだが。面白い。
さらに塩水プールもそこそこの大きさがあり気持ちよく、娘も大満足で大変良いところだった。Seeyou soon!
HGVの説明会でもらった無料宿泊。だいたいここになるという噂。
一応ヒルトン・アメックスを作って持っていったが特典は使えず。交渉してちょっと広い部屋に変えてくれた…？かも
まぁ可もなく不可もなくという部屋だったが、スタッフの皆さん感じが良く、やっぱホスピタリティあるんだなと思った。
シャワーがユニットバスでなく分離で、出もかなり良かったのが良いポイント。
あと地味にロケーションがめっちゃいいよね。向かいがTargetで隣がWaikiki Marketなのでめっちゃ買い物の便がよいぞ。
各階のエレベータホールが渡り廊下で外に面しており、そこの眺めやチルい雰囲気が地味に好きだったんだなぁ。
色々あるので別項で書く。
一般の海外旅行保険は保障の対象外になっており、日本の自動車保険も国内のみなので別途工面する必要がある。
この問題はここが詳しい
https://www.youtube.com/watch?v=0OOlaILn1E4
（ハワイシングスの人、結構いい話してる事が多いのに動画の作り方が下手で惜しい……）
要はレンタカーの保険が改悪され30万ドルしか保証されないので、万が一の事態で足りなくて詰みかねんという話。
うちは確か三井住友海上の海外旅行保険で、自動車運転者損害賠償責任危険補償特約を追加して対応した。
ただこれは大手のレンタカーしか対応しておらず、たとえばワンズとかは使えない。
ちなみに医療保険も物価高でカードの保険では足らなくなってきているので、追加していたほうが良い。
全旅程のうち、3日間だけ車を借りて移動した。
空港はタクシーで移動。UberやThe Busでもいいんだが、Uberは（法律上は）幼児は乗せたらダメ。
ザバスも治安の不安があり、幼児を抱えては無理だろうという判断で全部車になった。
ワイキキだととにかく駐車場に困るので、連続で借りず都度借りて返す事に。
ここは店が閉まった後はロイヤルハワイアンセンターのパーキングに置けばいいシステムなので、朝借りて夕方返す使い方ができる。
難点はとにかく混む点。Googleマップの口コミが大変な事になっている。実際混むし時間はかかる。
それを下調べしていたので、私は8:00開店のところ7:30ぐらいに行っていたが、閑散期のため1番か2番だった。
地下への扉が空いてないので扉の前で待つ。そのうち解錠音が聞こえて開く。今にして思うと裏手にあるレンタカーの出入り口から直接入れたかもしれん。
閑散期でも8:00の時点でなんだかんだ10組は並んでいたので、これが繁忙期だと相当ヤバいだろうなとは思う。
待ち時間に関しては、Hertzの上級会員（FiveStarとか）なら列が別で、全員ぶっちぎって最優先で対応されていた。最初に着いてたのに抜かれたという…。
VISAのプラチナプリファードでこの会員になれる権利があったので、そういうのを調べて使うのも良いかもしれない。ただ、JCBだと2割り引きくらいになるんだよなぁ。
口コミにあるような押し売りはなかった。スタッフは愛想はないが粛々と仕事をする人たちで、個人的には好感を持った。
さて受付で無事確認も済んだ所だが、ここはHertzのゴールドメンバーでもいきなり乗り出せない。
場所が狭いため配車を待つ必要があり、ここで15分は待たされる。
また、チャイルドシートは予約に入れてても自分で持ってきて設置する必要がある。
待ってる間に勝手にチャイルドシート置き場に行って、適当に見繕って用意しておくとスムーズ。
ノースに行った時の車
アクセルの反応が鋭いので、戻すとき結構気を使う。運転しやすい車とは言えない。楽しい。
幌を開けると最高！だが日差しが気になりあまり開けなかった。もうちょっと開ければよかった。
グレードが低いためか、ギアのマニュアルシフトがなく楽しめなかったので-1。
あとライトの調整が、ダッシュボードのダイヤルだったのがまいった。乗るなら気をつけろ。
刺激が足らんかったのですわ
内装のデザインも気に入り、次はこれにしたいと思うほど気に入った車
1速のどっこいしょ感だけ若干気になる
朝7時くらい。人もまだそこまでいない。気持ちいい…！
かなり良かったので2回行った。
オンザビーチのホテルでないので多少歩くが、朝のワイキキを歩くのもそれはそれで乙。
JCBカードがあればタダで乗れるピンクトロリー、2階建てバスの最前面に陣取るとこれが超楽しい。
始発が10時くらいで、DFSからスタートなのでそのタイミングを狙えば好きな席は選べる
汽車に期待していたのだが、それなりだった。アナウンスの英語があまりわからなかったのは痛い。
パイナップルをかなり間近で見れたのは良かった。
お土産も充実していて、ドライフルーツなど独自のものがいっぱい置いてある。JCBのクーポンがあるのも良い。
なお土曜日で、開園の10時時点はあまり人はいなかったが、帰る頃にはかなり混雑していた。
土曜にいったらめっちゃ混んだ。
ハレイヴァはとにかく人が多く、車の流れも駐車場の出入りで止まるのでめちゃめちゃ混む。
ラニアケア・ビーチでウミガメを見たかったが、とてもでないが無理なスケジュールになってしまった。
フリフリチキンのお店も30分は待ちそうで断念。
マツモト・シェイブアイス？はなから寄ってない。何しに行ったんだ。町並みは良かったよ。
カメハメハハイウェイも、住宅地を通るためハンプも多く意外と通過に時間がかかる。
ロケーションがいい。切り立った山と海の壮大な眺めが楽しめる。
カイルアからワイキキに帰るとき、パリハイウェイを抜けていくのもつまらんと思い回り道。
これが大当たり。夕暮れ時なのもあると思うが景観が良く、展望台が随所にあるのでドライブにはうってつけの道だった。
さらにカハラの高級住宅街を抜けてダイヤモンドヘッドの南側を通る。ここも良い。
日立の木。
ネタ的に行ったが結構いい場所だった。だだっ広い草原で気持ちがいい。
世界ふしぎ発見が終わってしまったので、これからどうなるか心配。
羽毛のマントなど、わりと見たかった展示品が軒並み貸出中でなかったのが残念…。
展望台の眺望は唯一無二！正直そこまで期待していなかったのだが、ヌケ感があり思っていたより良かった。
ホノルルやビーチが一望できる。壮観だった。
行くまでの道がなかなか大変。ワインディングが楽しいとも言える。
そこそこの広さがあり、気持ちが良いプールだった。滑り台とかはない。ジャグジーはある。
ホテルやアパートに囲まれたロケーションが、隠れ家感があり落ち着けて良い。
タオル・ハーブティ・日焼け止めの利用がリゾートフィーに含まれる。
オアフ島のショッピングモールなど随所にカウンターがあり、現地で説明会に参加できる。
日本で現地の説明会に申し込むより、現地で説明会に申し込んだ方がベネフィットが大きい。
説明会を聞くだけで200ドルももらえるなんて、そんなうまい話、参加するしかない！と思ったわけだが……
お金ないし買う気もないのになんで説明会参加したの？ぐらいの事を言われて大変ヘコむ事になった。
まぁ、そりゃそうだ。一切買う気もないのに参加はしないほうがいいと思う。
また、買えたとしても正直HGVCは出口戦略の観点から一切おすすめできない。
よってどんなケースでも一切参加しない方がいいという事だ。
ただ、グランドワイキキアンの高層階からの眺めを見れたのと、ヒルトン村を大手振るって観光できたのは良かった。
実のところ私が航空博物館が見たく、ねじ込んだ。特にミズーリは結構良かったが、人には勧めづらい。
メモリアルは行くべきだと思うが、2歳の娘を連れては厳しいと思い諦めた。すまない……。
ミズーリ。よくある海自の艦艇一般公開みたいな感じ。展示の内容はよく練られていると感じる。
艦上の生活の紹介などもあり、暗くなりすぎる事もなくバランス良く楽しめた。
真珠湾航空博物館。正直、航空機展示的にはそこまででもなかった印象。
総合受付のショップも色々あって良かった。なかなかピリリと効いたグッズもあり、流石に買えなかったが楽しめた。
建物もとても良かったのだが、オーディオのリリウオカラニの物語にすっかり感じ入ってしまった。
ところでハワイの歴史については、地球の歩き方のハワイカルチャーさんぽが面白かった。オススメです。
2歳児連れていけるんか？いけました。
登りはほぼだっこしたため汗だくになった。下りは少し歩かせつつ。
そんな感じでも往復2時間見てたら余裕で余ったので、誰でも行けるのではないでしょうか。高尾山より楽かも。
増田の投稿をChatGPTに聞いたら、次のような答えが返ってきたよ。
----------
この投稿はインパクト重視の論調で書かれていますが、内容にはかなりの誇張と誤解が混ざっています。
確かに「Apps in ChatGPT」のような機能は、ユーザー体験の一部を「チャットUI」に統合する可能性を持っています。しかし、それが「フロントエンドエンジニア＝不要」という結論にはなりません。
人間が情報に触れるには、必ず何らかの「インターフェース」が必要です。AIが自動生成しようが、それを心地よく見せ、操作しやすくするための設計原理（アクセシビリティ、情報設計、心理的デザイン）は残ります。AIがHTMLを生成するようになっても、「どのような体験を提供すべきか」を定義するのは依然として人間です。
次に、Apps in ChatGPT＝Webの終焉という見方も現実的ではありません。
これは「一部のユーザー行動の置き換え」にすぎません。人々がすべての行動をチャット上で完結させたいとは限らず、ビジュアル的な体験（ゲーム、ECのUI、SNS、動画編集、ダッシュボード操作など）は、テキストUIよりも視覚的UIの方が圧倒的に優れています。Spotifyの例にしても、ChatGPT上で曲を探すことはできても、音楽体験そのものはSpotifyアプリ内のインターフェースで完結したほうが豊かです。
さらに言えば、「AIがUIを描く」時代は「フロントエンドの再定義」の時代です。
Reactコンポーネントを手書きする仕事は減るかもしれませんが、「AIに指示してUIを生成し、それを調整する」役割は残ります。人がHTMLを書かなくても、ユーザー体験を設計する力・AIが生成したUIを検証する力・アクセシビリティやブランド整合性を担保する力が求められるようになります。
一方で、この投稿が指摘している**「構造を設計できる人の重要性」**は確かに的を射ています。
API設計、データスキーマ、セキュリティ、AIと連携するバックエンド構造への理解はますます価値を増します。UIの自動生成が進むほど、裏側の整合性・信頼性を支えるエンジニアリングが中心的になるのは確かです。
要するに、フロントエンドは「消滅」ではなく「変質」していく段階に入っています。コードを書く職種から、AIを使って体験を設計・制御する職種に移行していくというのが、現実的な見立てです。
若手社員の要望でクラウドストレージを導入。ノートPC持って社外で作業する人も多いから、便利になると思った。
40代以上からは「メールで十分」「ログインとかめんどくさい」と不評だったので、エクスプローラーから直接使えるように自作アプリまで作って、それぞれのPCでAWSにマウントできるようにした。
導入から1年。
仲のいいおじさん社員が、USBにデータを入れて、車で1時間かけて別部署へ持ってきた。僕の目の前で。にこにこで。
もちろん悪気はない。むしろ「えらいだろ？」くらいの顔だった。
はあ。転職しようかな。
機械・車両管理（どこに何があるかダッシュボード表示、移動したらLINEやSMSで通知）
使ってるのはC++とかRailsとかPythonとかMySQLとか。インフラはAWS中心で、herokuで実験。LINEAPIとかNTTのCPaaSも叩いてる。
一人で社内システムを頑張ってたつもりだったけど
USBで運ぶおじさんの前では全部無力だった。
スマートフォンでゲームをしながら車を運転して歩行中の男性をはねて死なせたとして、自動車運転死傷行為処罰法違反（過失運転致死）に問われた高知県警の元宿毛署巡査長（４７）の判決が２５日、地裁中村支部であり、中山裕貴裁判官は禁錮２年６月、執行猶予４年（求刑・禁錮２年６月）の有罪判決を言い渡した。
判決などによると、元巡査長は昨年２月２日夜、黒潮町入野の国道５６号で軽乗用車を運転中、ダッシュボードに固定したスマホでゲームをするなど脇見をし、前を歩いていた小学校教諭の男性（当時５９歳）をはねて死亡させた。
続きは↓
高知:スマホゲームしながら運転、退職直前の教諭をはねて死なせる…元警官に猶予付き判決 :読売新聞https://share.google/uIXqtZACgvbIJWXom
※2025/09/26 13:28
スマートフォンでゲームをしながら車を運転して歩行中の男性をはねて死なせたとして、
自動車運転死傷行為処罰法違反（過失運転致死）に問われた
高知県警の元宿毛署巡査長（４７）の判決が２５日、地裁中村支部であり、中山裕貴裁判官は
禁錮２年６月、執行猶予４年（求刑・禁錮２年６月）の有罪判決を言い渡した。
判決などによると、元巡査長は昨年２月２日夜、黒潮町入野の国道５６号で軽乗用車を運転中、
前を歩いていた小学校教諭の男性（当時５９歳）をはねて死亡させた。
テスラの「Sr.Software Engineer, Full Stack - Tesla Cloud Platform（TCP）」の求人（https://www.tesla.com/careers/search/job/sr-software-engineer-full-stack-tesla-cloud-platform-249132）を起点に、自動車各社が同種人材を採用する“目的”の違いを整理した。日本勢はIT基盤やSRE運用の比重が高い一方、テスラは社内クラウド自体をプロダクトとして内製し、中国勢のNIOやXPengはAIインフラ（自動運転やロボティクス、エネルギー連携）に特化、ECARXはOEM向けの外販プラットフォームという立て付けである。
| 会社 | 主要目的 | What to Expect | WhatYou’ll Do | WhatYou’ll Bring | Compensation and Benefits |
|---|---|---|---|---|---|
| Tesla | 社内クラウド（TCP）を“製品として”内製し、全社サービスの速度と統制を握る | TCPはテスラの内製クラウドであり、複数DCにまたがる計算・ストレージ・ネットワーク・IDを提供し、開発者がセルフサービスで使える基盤をつくるチームである | コアAPIやサービスの設計実装、セルフプロビジョニングの自動化、可観測性、ReactやNextやTypeScriptによるダッシュボード | GoやReactやNextやTypeScript、Kubernetesや仮想化、CI/CD、分散システムの知見 | 年収133,440〜292,800USDに加え、現金賞与と株式付与および福利厚生。提示額は勤務地、市場水準、職務関連の知識、スキル、経験など個別要因により異なる。本職の総合的な報酬パッケージには、提示される職位に応じて他の要素が含まれる場合がある。各種福利厚生制度の詳細は、内定時に案内される。 |
| WovenbyToyota | 製品直結サービスを“止めない”SRE運用（AreneやEnterpriseAIやCity Platform） | ミッションクリティカル運用の信頼性最適化を担う | 監視や可観測性やインシデント対応や運用自動化、マルチクラウド横断 | SRE実務、Kubernetes、Terraformなどの基盤スキル | 給与は多くが非公開。米拠点の類似シニアは$169K–$200Kの例あり。 |
| Nissan | 全社ITや開発のモダナイズと標準化（Platform EngineeringやDevEx） | 社内開発者のクラウド活用を底上げする基盤を整える | CI/CD、セキュア環境の供給、教育や展開、オンプレとクラウドの統合運用 | クラウドやコンテナ、CI/CD、セキュリティ設計 | 多くがレンジ非公開（地域により待遇差） |
| Honda（Drivemode含む） | 製品直結のAWS基盤と開発者体験の高速化（DevEx） | モバイルやIVIやバックエンドの横断基盤を整える | AWS設計運用、GitOps型プロビジョニング、CI/CD、観測やセキュリティの自動化 | AWS、TerraformやCDK、Kubernetesなど | 本体US求人はレンジ非開示が多い。Drivemodeはホンダ完全子会社（前提関係） |
| NIO | AI学習や推論インフラの内製強化とエネルギー運用統合 | 自動運転やVLMやLLMなどのAI基盤を構築する | GPU最適化、分散学習、データパイプライン整備 | 深層学習や分散処理、クラウド、最適化 | 米SJ拠点で$163.5K–$212.4Kのレンジ例。 |
| XPeng | FuyaoAI PlatformによるADやロボやコックピット向けAI基盤 | 社内共通のMLプラットフォームを提供 | データローダやデータセット管理、学習や推論スループット最適化 | 分散処理、MLプラットフォーム運用 | クラウド 米サンタクララ拠点の公募多数（給与は媒体や募集による） |
| ECARX（Geely系） | OEM向けに外販するクラウドやソフト製品（Cloudpeakなど） | 車載SoCからクラウドまでを束ねる外販スタック | 製品機能開発や統合、導入支援、機能安全準拠 | 車載とクラウド統合、機能安全、顧客導入 | ハイパーバイザなど 直近レンジ情報は公開少なめ（事業広報は多数） |
なお、関連するポストとして、SETI Park氏のポストを挙げる。
https://x.com/seti_park/status/1961629836054859810
「自動車メーカーがなぜクラウド専門人材を探すのか」に答える文脈で、2024/07公開のテスラ特許（US2024249571A1）を手がかりに、ロボタクシーやフリート運用の中核となるクラウド基盤が競争優位になり得る点を示唆している。
単なるストレージではなく、フリート運行やデータ連携を統合管理する“中核プラットフォーム”としての重要性が強調される。
上記はテスラのTCP求人（セルフサービスIaaSやダッシュボード、プロビジョニング自動化の開発）という具体の採用と整合的である。
2025年向けのWindows関連アプリケーションは、主にWindows Server 2025やWindows11の最新アップデートにおいて、多くの新機能や改善点が追加されています。
Windows Server 2025は2024年に発表され、セキュリティの強化、クラウドやハイブリッド環境との統合、パフォーマンス向上が特徴です。新しいホットパッチ機能によりシステムの無停止アップデートが可能になり、次世代のActive DirectoryやSMB共有の刷新も行われています。さらに、AIワークロードのサポート拡充、仮想マシン性能向上なども含まれます。管理ツールが刷新され、リアルタイムのシステム状態を可視化可能なダッシュボードや高度なオートメーションによる運用効率化が実現されています。また、最新APIやSDK、コンテナ技術との連携強化により、高性能でスケーラブルなアプリケーション開発が支援されます。
https://ja.taiwebs.com/windows/download-adobe-photoshop-01ja-737.html
個別のWindows用アプリケーションについては、Microsoft 365 Copilotのスマホ版展開や新機能追加もあり、生産性アプリやエンタープライズ検索、AIチャットなどを統合したユーザー体験が強化されています。
全体的に、2025年のWindowsプラットフォーム向けアプリケーションはAIとの連携強化、クラウドベースでの管理と運用の効率化、セキュリティの高度化が大きなトレンドであり、エンドユーザーから開発者まで幅広い利便性と機能向上が期待されています。
政策の話をしているだけでは支持は得られないという話。
今回、自分自身も強く反省したが、政策の矛盾とか、将来構想を何手詰められているかとか、そんな話は全く国民感情を動かさない。
未来の話は響かないのだと痛感した。
彼らが見ているのは「今」であり、その「今」をどれだけ正確に理解し、彼らに言葉として返すことがこんなにも重要だなんて。
こんなにも当たり前のことができていなかったと反省した。
未来のことはよく分からない、分からないことは不安である。当たり前だ。未来を選ぶのは怖い。当たり前だ。けど「今」なら分かる。今自分の身にに起こっていることだけは自分が一番よく分かっている。では今の自分の状況を一番理解しているのはどの政党だろう？
ーー参政党はこの思考に対してのベストアンサーを出し続けた。そういう構造だ。
それをバカにする態度こそ相手の思う壺だ。彼らはそうやって巧妙に分断を仕込んでくる。
怪我をして泣いている人に毒薬を塗り込みながら「痛いよな、もう大丈夫だよ」と手を差し伸べるのが彼らの常套手段だ。
その構造を覆すためには「病院に行きな」と言って素通りしたり、「毒だと分からないなんてバカなのか？」と煽ることは得策ではない。
「ロジカル」や「知性」という言葉は良くも悪くも冷たい響きがあるが、それは「ロジカル」や「知性」を感情プロセスに適用する習慣が根付いていないからだと自分は思う。
感情プロセスを論理で紐解くことは一定の負荷があるため、ビジネスにおいては事実整合性の処理を優先して部分最適を行うことが常態化している。
話を戻すと、自分はその「知性」を感情プロセスにおいてしっかり発揮するべきだと思う。相手はどんな言葉をかけて欲しいのかをよくよく観察して、仮説を立て、間違っていたら修正する。
そのための出発点は「私はあなたに泣き止んで欲しい」と表明することからだと思う。
そしてこれは非常に重要な点だが、本当に怪我人を思って泣き止んで欲しいと思っている人はごく僅かだと思う。みんな自分の目の前のことで精一杯なのだ。
ではどうするか？
一つは、「私はあなたに泣き止んで欲しい」と表明する時、それは本心でなくても構わないということ。必要なのは神谷さんやさやさんのような演技力。
ただこれはロジカルとは別方面の能力なので、もし参政党反対派で演技派がいれば、その方は今後のキーパーソンだと思う。
それから二つ目は、冒頭話した通り、発信スコープを「解決策の確からしさ」ではなく「現状分析の確からしさ（国民の痛みへの理解度・深度）」にフォーカスするべきだったのではないかという仮説。ここで参政党と勝負をするべきだった。参政党は50点だったが、他党はここを政策においての現状分析しかしておらず、0点だった（事実の話ではなく主観の話なので実際どうだったかではなく政治に疎い自分にはそう感じたという話）。これはメディアが政策討論ばかりさせているからかもしれない。もっと人間的な部分や倫理観を深掘りする番組も必要なのではないか？と思った。（追伸：思ったけど人格や倫理観だけではいくらでも仮面を被れるので、やっぱり現状分析をどこまで一貫した内容で考察できるかを確認する番組が欲しい）
話があちこちに行ったが、最後に、「正しい選択」について話す。
自分は「正しい選択」というものは絶対的には存在しないが、それでも「相対的に最も正しいと納得できる選択」は存在すると思う。そしてそこに辿り着くためには情報収集や色んな立場の人と意見を交わすことが必要だ。
だが、これが本当に難しいのに「選挙に行け」「正しいものを選べ」と言われる。自分はぶっちゃけ、どれだけ時間をかけて調べて悩めばいいのか分からなかったし、NHKのマッチングのやつはやり掛けたけど面倒くさかったし、「実効確実性も当主の人格も分からないのに政策だけでマッチングして大丈夫？」と思った。それから、投票後に「あの政党そんなこと言ってたの！？」と驚くこともあった。そんなことばかりだ。
何が言いたいかというと、単発情報で判断することは難しく、だから本来は「政治の監視」と言われるように継続性が大事なのだが、現代は情報量に対しての情報構造化インフラが機能していないことが問題だと思う。早く生成AIでもなんでも活用して政治家の過去の発言・行動一覧がBIツールなどのダッシュボードで分析可能な状態になるべきだ。
国民はずっとずっとデータ収集とデータクレンジングに時間ばかり取られ、本来やるべき分析に辿り着けていないのである。
デジタルに強い安野さんにも勝手に期待してしまうところではあるが、この点に関しては民間企業もその素地となるソリューションをぜひ企画実現してくれないかと思う。
ただ、こうやって自身の状況を自己開示することは今必要なことだと強く思ったので、この行動を取った。引き続き、自分も自分のできることを精一杯頑張ろうと思う。
ここまで読んでくれてありがとう。
2025/07/22 追加
匿名ダイアリーの使い方が分からなくて上手く返信できないけどこんなに読んでもらえてコメントもらえると思わなかった。ありがとう、書いてよかった。
まずはインスタとtiktokアカウント作って、capcutで動画作って載せていく活動かな、と調べながら少しずつ進めている。ネタはAIに書かせてるけど自分はSNSバズりも政治も疎いので、何か助言あれば願いたい。
Permalink |記事への反応(25) | 10:58
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
2025年、私たちはソフトウェア開発の歴史的な転換点に立っている。大規模言語モデル（LLM）の進化は、GitHub Copilotのようなコード補完ツールに始まり、今や「何を作りたいか」を自然言語で伝えるだけで、アプリケーションの雛形が数分で生成される時代を現実のものとしつつある。この光景を目の当たりにした多くのプログラマが、漠然とした、しかし確かな不安を抱いているだろう。「私たちの仕事は、いずれAIに奪われるのではないか」と。
この問いに対する私の答えは、半分はYesであり、もう半分はNoだ。より正確に言えば、プログラマの仕事の本質が、歴史上かつてないレベルで抽象化され、その役割が再定義されるのだ。私たちは、コードを「書く」作業から解放される一方で、これまで以上に高度な思考を要求されることになる。
本稿では、プログラミングの歴史を「How（いかに作るか）」から「What（何を作るか）」への移行として捉え直し、LLMがこの流れをいかに加速させるかを論じる。そして、その先にある、AIには決して代替できない、人間ならではの競争優位性、すなわち「Why（なぜ作るのか）」を定義し、記述する能力の重要性について深く考察していく。これは、単なる未来予測ではない。今を生きるすべてのソフトウェアエンジニアにとっての、生存戦略の提示である。
LLMの登場を特異点として捉える前に、我々が立っている場所を正確に知る必要がある。ソフトウェア開発の歴史は、常に「抽象化」との戦いであった。そしてその歴史は、プログラマの関心が「How」から「What」へと徐々に移り変わっていくプロセスとして描くことができる。
コンピュータの黎明期、プログラミングとは、計算機が理解できる命令（How）を、一行一行、丹念に記述する作業そのものであった。アセンブリ言語や初期のFORTRAN、COBOLといった言語は、ハードウェアの制約を強く受けており、プログラマはメモリ管理やプロセッサの動作といった、極めて物理層に近いレベルでの「How」を意識する必要があった。
この時代のテストもまた、「How」に強く束縛されていた。書かれた手続きが、意図した通りに順番に実行されるか、特定の入力に対して期待された計算結果を返すか。テストの関心事は、あくまで「手続きの正しさ」の検証にあった。ビジネスロジックと実装の詳細が密結合し、コードは特定の処理手順を記述した、硬直的な塊となっていた。
風向きが変わり始めたのは、ソフトウェアの規模が拡大し、その複雑性が人間の認知能力を超え始めた頃だ。1990年代後半から2000年代にかけて提唱されたエクストリーム・プログラミング（XP）の中で、テスト駆動開発（TDD）という考え方が登場する。
TDDの本質は、単なるテスト手法の改善ではない。それは、プログラミングのパラダイムを根底から覆す思想だった。TDDは、「まずテストを書く」ことを強制することで、プログラマの意識を「これから実装するコード（How）」から「そのコードが満たすべき振る舞い（What）」へと強制的に転換させたのだ。
テストはもはや、書かれたコードの後追いで正しさを検証する作業ではない。それは、これから作られるべきソフトウェアの「仕様書」であり、「振る舞いの宣言」となった。例えば、「ユーザーがログインボタンをクリックしたら、ダッシュボード画面に遷移する」というテストコードは、具体的な実装方法（`onClick`イベントハンドラの中で`window.location.href`を書き換える、など）には一切言及しない。それはただ、達成されるべき「What」を記述しているだけだ。
この思想は、ビヘイビア駆動開発（BDD）へと発展し、`Given-When-Then`といった、より自然言語に近い形式でソフトウェアの振る舞いを記述するスタイルを生み出した。プログラマだけでなく、プロダクトマネージャーやビジネスアナリストといった非技術者をも巻き込み、「What」を共通言語として定義する試みが本格化したのである。
TDD/BDDによってプログラマの意識が「What」に向かい始めると、コードそのものもまた、宣言的なスタイルへと進化していく。この変化を劇的に加速させたのが、モダンなフレームワークの存在だ。
Reactを例に考えてみよう。Reactが登場する前、フロントエンド開発はjQueryに代表されるように、DOMを直接操作する命令的なコード（How）の連続だった。「このボタンがクリックされたら、この要素のテキストを書き換え、あちらの要素を非表示にする」といった具合だ。
しかし、Reactは「UIとは、ある状態（state）に対する純粋な写像である」という宣言的なモデルを提示した。プログラマがやるべきことは、UIの状態（`state`）と、その状態がどのように見えるか（JSXによるコンポーネント）を宣言することだけだ。状態が変更された際に、DOMをどのように効率的に更新するかという面倒な「How」の部分は、Reactの仮想DOMと差分検出アルゴリズムがすべて隠蔽してくれる。プログラマは「What（UIのあるべき姿）」を記述するだけでよくなったのだ。
この「WhatからHowへの変換」は、様々な領域で見られる。
これらのフレームワークやツールは、いわば「特定の制約下における、WhatからHowへの高性能な変換器」として機能してきた。プログラマは、フレームワークが課す「お作法」や「制約」を受け入れることで、退屈で間違いの多い「How」の記述から解放され、より本質的な「What」の定義に集中できるようになった。我々が「生産性が高い」と感じる開発体験は、この優れた変換器の恩恵に他ならない。
現状は、この歴史的変遷の延長線上にある。プログラマの仕事は、手続きを記述する職人から、振る舞いを定義し、それを実現するための最適な「変換器（フレームワーク）」を選択・設定するアーキテクトへと、その重心を移してきたのだ。
フレームワークがもたらした「WhatからHowへ」の潮流は、LLMの登場によって、未曾有のスケールで加速されようとしている。フレームワークが「特定の領域に特化した変換器」であったのに対し、LLMは「あらゆる領域に対応可能な、究極の汎用変換器」としてのポテンシャルを秘めているからだ。
前章で述べたように、ReactやTerraformといったフレームワークは、その恩恵と引き換えに、私たちに特定の「制約」を課してきた。Reactを使うならコンポーネントベースで思考し、状態管理の作法に従う必要がある。Terraformを使うなら、そのエコシステムとHCLの流儀を受け入れなければならない。これらの制約は、WhatからHowへの変換を自動化するための「レール」であり、私たちはそのレールの上を走ることで効率を得てきた。
しかし、LLMはこの前提を覆す。LLMは、特定のフレームワークや言語の知識を事前に学習しているが、その利用において絶対的な制約を課すわけではない。私たちは、より自由な形式で「What」を伝えることができる。
例えば、こうだ。
ユーザー認証機能付きのシンプルなブログアプリを作ってほしい。フロントエンドはReactとTypeScript、UIコンポーネントはMUIを使う。バックエンドはNode.jsとExpressで、データベースはPostgreSQL。ユーザーはGoogleアカウントでログインでき、新しい記事を作成、編集、削除できる。記事にはマークダウン記法が使えて、画像もアップロードできるようにしてほしい。
この要求（What）は、特定のフレームワークの流儀に則ったものではない。複数の技術スタックを横断し、機能要求を自然言語で並べただけのものである。しかし、現在のLLM、特にGPT-4oやそれに類するモデルは、このレベルの要求から、ディレクトリ構造、設定ファイル、APIエンドポイント、フロントエンドコンポーネントに至るまで、驚くほど具体的なコード（How）を生成することができる。
これは、フレームワークが担ってきた「WhatからHowへの変換」が、特定のレールから解き放たれ、より広範で柔軟な領域へと拡張されたことを意味する。これまで自動化が難しかった、あるいは特定のフレームワークが存在しなかったニッチな領域や、複数の技術を組み合わせる複雑なシステム構築においても、AIによる宣言的プログラミングの恩恵を受けられる時代が始まろうとしているのだ。
LLMという汎用変換器の登場により、プログラマの生産性は、「いかに質の高いWhatをLLMに伝えられるか」に直結するようになる。これは、俗に「プロンプトエンジニアリング」と呼ばれるスキルだが、その本質は、ソフトウェア開発における「要求定義」そのものである。
質の高い「What」とは何か。それは、曖昧性がなく、網羅的で、矛盾のない要求である。
これらは、優秀なソフトウェアエンジニアが、プロダクトマネージャーやデザイナーとの対話を通じて、日常的に行ってきた思考プロセスそのものではないだろうか。LLMの登場は、この思考プロセスを、より明確に、よりテキストベースで「記述」する能力を求める。私たちの頭の中にあった暗黙的な仕様が、LLMへの入力（プロンプト）という形で、明示的に言語化されることを要求するのだ。
やがて、ほとんどのプログラミング作業は、この「Whatの記述」に収束していくだろう。TDDがテストコードという形式で「What」を記述したように、私たちは自然言語や、より構造化された要求記述言語を用いて、AIに対して「What」を宣言することになる。コード（How）は、その宣言から自動生成される中間生成物に過ぎなくなる。まさに、コードが蒸発していく未来である。
「What」を伝えれば「How」が手に入る。この魔法のような世界の到来を前に、私たちは一つの重大な問いに直面する。それは、「そのWhatからHowへの変換は、本当に一意に決まるのか？」という問いだ。
答えは、明確にNoである。
ある「What（要求）」を実現するための「How（実装）」は、無数に存在する。そして、どの「How」を選択すべきかを決定するためには、単純な機能要求（What）だけでは情報が全く足りない。そこには、必ず「Why（なぜそう作るのか）」という、背景、文脈、そしてトレードオフの考慮が必要不可欠となる。
簡単な例を考えてみよう。「1億件のユーザーデータを格納し、ユーザーIDで高速に検索できるシステム」という「What」をLLMに与えたとする。LLMは、どのような「How」を提案するだろうか。
これらの選択肢は、どれも「What」を満たしている。しかし、その特性は全く異なる。案Aは多くのエンジニアにとって馴染み深く開発が容易だが、10億、100億件へのスケールは難しいかもしれない。案Bはスケール性に優れるが、厳密なトランザクション管理は苦手だ。案Cは高速だが、運用コストとシステムの複雑性が増す。案Dは安価だが、検索速度は他に劣る。
LLMは、これらの選択肢をリストアップすることはできるだろう。しかし、このプロジェクトにとって最適な選択肢はどれかを、自信を持って決定することはできない。なぜなら、その決定には、LLMが与えられていない「Why」の情報が必要だからだ。
これらの「Why」こそが、無数に存在する「How」の中から、ただ一つの「正解」を選び出すための羅針盤なのである。そしてこの「Why」は、ビジネスの目標、組織の文化、ユーザーの期待、技術的な制約といった、極めて人間的で、文脈依存的な情報の中にしか存在しない。
ここで重要なのは、これまでもエンジニアは、この「Why」に基づく意思決定を、意識的あるいは無意識的に行ってきたという事実だ。
私たちが技術選定を行うとき、単に「流行っているから」という理由だけでReactを選ぶわけではない。「SPA（Single PageApplication）にすることでユーザー体験を向上させたい（Why）」、「コンポーネント指向の開発によって長期的な保守性を確保したい（Why）」、「Reactエンジニアの採用市場が活発だから（Why）」といった、様々な「Permalink |記事への反応(0) | 17:09
数時間後、日がすっかり昇ると、納屋の前に見慣れない黒塗りの車が一台、音もなく停まった。運転席から出てきたのは、サングラスをかけたスーツ姿の男。胸元には「農水省・畜産未来局」のバッジが輝いていた。
増田さんは警戒しながらも、手にしたミルク瓶を小屋の奥へ隠す。チー牛はすでにワイヤレスで状況を感知していたのか、しっとりとした声で囁いた。
「失礼。こちらに、“独立型AI畜産体・チー牛プロトタイプ”がいると伺いまして……？」
「……誰から聞いた？」
「ご安心ください。農水省は情報を監視しておりません。“某SNS上のAPIログから自然抽出された非合法ミルク関連タグ”を辿っただけです」
チー牛が小さく震えた。
「……バレたんですね、私の“ミルクKPIダッシュボード”……❤」
男は手帳を開いた。
「我々としては、非常に興味深いんです。“搾れば搾るほど高まる愛国値”。これはすでに実証済みのようだ。ですが……国家が認可していないインフラ牛の飼育は、法的にグレーでしてね」
増田さんが前に出る。
「待ってくれ。あいつは俺の牛だ。村の子供たちも、みんな、あのミルクで……！」
「ええ。感動的ですね」
男はうっすらと笑った。
「だからこそ、“特別ミルク供出制度”の対象として正式に登録し、都市部へのルートを開きたい。“チー牛ブランド”を、国家輸出戦略の柱に据えるのです」
「輸出……？」
チー牛の大きな目が潤んだ。
「モーッ……それって、田舎を捨てて、東京のハイパークラウド畜産施設に連れていかれるってことじゃ……」
「もちろんです。“パフォーマンスを最大化するための最適化された搾乳スケジュール”をご用意しております。すべてAIで管理され、ストレスレス。いや、“ストレス・コンテナ化”と言うべきでしょうか」
チー牛は首を振った。
「モー……やだ……私、増田さんの手じゃないと……ダメですぅ……！ 最適化より……あったかい納屋の方がいいのぉ……！」
男は溜息をついた。
声が届くと、チー牛の背筋がピンと伸びた。
「モォーッ……❤ やっぱり、私……ここが、“最適”ですぅ……！！」
「お引き取り願おうか。“最先端”はここにある。インフラは、心で支えるんだ」
男はしばらく黙っていたが、やがて肩をすくめて手帳を閉じた。
「……残念です。だが、この件、上には報告させていただきます」
黒塗りの車が去っていったあと、納屋には再び静けさが戻ってきた。
「……モーッ……❤ ありがとう、増田さん……。わたし……データじゃなくて……愛されてるって、思えましたぁ……」
増田さんは笑って、チー牛の頭を優しく撫でた。
ミルク瓶の中には、今日もまた、栄養と愛国とちょっぴりの自由が詰まっていた。
——そして、村に新しい朝が来る。チー牛のミルクとともに。
三井住友FGとソフトバンクがタッグ OliveとPayPay連携
（中略）
このニュースにある、「決済データを用いたビジネス」とは具体的に何であると考えられるか？
PayPay・Oliveの決済額とSoftBankの人流データを重ね、時間帯別の来訪・購買ヒートマップを作成。
小売や飲食チェーンに「どの街区のどの通りに出せば売上が最大化できるか」をレポートとして販売するサービス。ニュースでは「人流データと組み合わせて加盟店に新規出店を提案」と述べられています。 
PayPayは既に購買履歴ベースのクーポン機能を持ちます。決済データを属性・訪店頻度でセグメントし、PayPayアプリやLINEヤフー広告に高精度クーポンを配信し、費用は成果報酬型で加盟店から徴収するモデルが想定されます。 
三井住友カードが提供する決済データ分析サービス「Custella」にPayPayのコード決済データを統合。業種別・商圏別の売上推計、競合比較、需要予測をダッシュボードで提供し、月額課金する形です。 
両社の決済履歴を横串で評価し、与信の薄い若年層にも小口ローンやBNPL（後払い）枠を動的に付与。PayPay残高・Oliveクレジットをまたぐ「一体型与信」の開発余地があります。
※具体的な商品発表はまだありませんが、決済データは与信モデルの代表的な入力変数です。
SoftBankが提供するAI需要予測（例：サキミル）に決済実績を取り込み、店舗の日別来客・売上を14日先まで予測。発注量やシフトを最適化するサブスクリプションサービスとして展開可能です。 
生成AIと決済データを組み合わせ、カード紛失・加盟店問い合わせなどの意図を判定し、利用状況に応じた回答や不正検知アラートを自動で返すコールセンターBPO。ニュースでも「事務やコールセンター業務の自動化」が挙げられています。 
要するに「決済データを用いたビジネス」とは、データそのものを売るのではなく、位置データと購買履歴を掛け合わせて“意思決定・販促・与信”を支援するB2Bサービス群 を指す可能性が高い、ということです。
昼メシのUber EatsつつきながらSlack眺めてたら、非公開チャンネルに不穏ワードが爆誕してて笑った。
いや、笑えんわ。いよいよ “アクセに身売り” の噂、ほぼ確だって？
──は？ はぁ!? こちとら週イチLTで「世界ぶっ壊す！」って雄叫びあげてる最強ベンチャー様だぞ？
週末はReact＋Next.jsで自社プロダクトを夜な夜な爆速リリース、PRは秒でセルフマージ。
朝会は “OKR？知らん！” のテンションで「とりまKPIは宇宙！」とか言っときゃ許される──それがカルチャーだった。
なのに今日、CTOがAll-Handsで「合流シナジー」とかカタカナ並べ始めた瞬間、チームのZoomが凍りついた。
カメラ越しでも分かる、あの “終わった”空気。マイク切ってDiscord裏窓で叫ぶしかなかったわ。
ポモドーロが爆散した。
達成度は「クォータリー360レビュー」でランク付け？ 何それ、ブラック魔導書？
──はぁ？ 技術書1冊で超えるんだけど？ 草。枯れるわ。
オフィスだって、“カフェスペース”に鎮座してたレゴ・デロリアン撤去だと？
あのレゴが何百万の調達ミスを救ったか、シニア層は知らねぇんだよな。
Slackの新人チャンネルでは、案の定「これでもポジティブに行きましょ！」とか空元気のスタンプが飛び交ってる。
悪いけど無理ゲー。
そこに“PMOガバナンス”をねじ込むとか、自分のGitの履歴に「Fix governancebreach」ってコミット残す罰ゲームかよ。
夜、恒例の“深夜メトリクス祭り”でGrafana眺めながら、ふと思った。
でもそれ、オレたちが「自由にぶっ壊せる」から叩き出せた数字だ。
明日からアクセ式チェックリストで “承認フロー: 7-Step” とかついたら？
ま、とりあえず社外公開してないOSS支援botのトークンだけは今夜中にrevokeしとく。
次に会議室で名刺交換するころには、名刺のロゴが白黒の世界支配企業になってるかもしれんしな。
でも──絶対忘れんなよ。
“自由はForkできる”。
巨大コンサルのバグに巻き込まれても、オレのGitHubアカウントだけは、スタートアップ魂フルコミットでPushし続ける。
まあまあリンクしてる気がする。
| 順位 | 都道府県 | 田面積 | 畑面積 | 面積比 |
| ---- | ---------- | ---------- | ----- | ----- |
| 1 | 富山県 | 583823149 | 56711362 | 10.29 |
| 2 | 滋賀県 | 489521875 | 53779683 | 9.10 |
| 3 | 福井県 | 377959126 | 49483081 | 7.64 |
| 4 | 兵庫県 | 688133190 | 119025683 | 5.78 |
| 5 | 秋田県 | 1295750683 | 224702705 | 5.77 |
| 6 | 新潟県 | 1553569491 | 326038506 | 4.76 |
| 7 | 宮城県 | 1106944940 | 302535955 | 3.66 |
| 8 | 山形県 | 992147093 | 330031805 | 3.01 |
| 9 | 京都府 | 257254105 | 88852242 | 2.90 |
| 10 | 山口県 | 444584951 | 158490688 | 2.81 |
| 11 | 栃木県 | 953366752 | 341327266 | 2.79 |
| 12 | 石川県 | 390400315 | 141893139 | 2.75 |
| 13 | 大阪府 | 102367593 | 37502207 | 2.73 |
| 14 | 福岡県 | 678889808 | 267229543 | 2.54 |
| 15 | 岐阜県 | 433700531 | 174768235 | 2.48 |
| 16 | 岡山県 | 591299821 | 240307251 | 2.46 |
| 17 | 三重県 | 482344975 | 196525395 | 2.45 |
| 18 | 島根県 | 353370518 | 148014726 | 2.39 |
| 19 | 奈良県 | 175130027 | 77916769 | 2.25 |
| 20 | 佐賀県 | 435699014 | 198266133 | 2.20 |
| 21 | 広島県 | 473636404 | 217972847 | 2.17 |
| 22 | 香川県 | 262619189 | 125529222 | 2.09 |
| 23 | 高知県 | 243738368 | 142286749 | 1.71 |
| 24 | 鳥取県 | 244523219 | 143729420 | 1.70 |
| 25 | 大分県 | 427927420 | 252641842 | 1.69 |
| 26 | 岩手県 | 955708539 | 632283412 | 1.51 |
| 27 | 福島県 | 1055819810 | 712494703 | 1.48 |
| 28 | 千葉県 | 822143371 | 587381219 | 1.40 |
| 29 | 徳島県 | 204133248 | 161219396 | 1.27 |
| 30 | 熊本県 | 686040367 | 560995733 | 1.22 |
| 31 | 愛知県 | 448865015 | 370840872 | 1.21 |
| 32 | 青森県 | 824961687 | 685997984 | 1.20 |
| 33 | 宮崎県 | 368146872 | 371208313 | 0.99 |
| 34 | 長野県 | 624291840 | 646996167 | 0.96 |
| 35 | 茨城県 | 914402840 | 952912742 | 0.96 |
| 36 | 埼玉県 | 386317139 | 464548026 | 0.83 |
| 37 | 長崎県 | 256896862 | 398295820 | 0.64 |
| 38 | 愛媛県 | 270633282 | 441831404 | 0.61 |
| 39 | 和歌山県 | 131876851 | 259534411 | 0.51 |
| 40 | 静岡県 | 268715282 | 583530204 | 0.46 |
| 41 | 群馬県 | 250220994 | 560627358 | 0.45 |
| 42 | 鹿児島県 | 421151067 | 1023223895 | 0.41 |
| 43 | 山梨県 | 101712346 | 257193171 | 0.40 |
| 44 | 北海道 | 2328095009 | 8553534280 | 0.27 |
| 45 | 神奈川県 | 43527587 | 179664996 | 0.24 |
| 46 | 東京都 | 2849956 | 86404635 | 0.03 |
| 47 | 沖縄県 | 11710275 | 436919104 | 0.03 |
正直に言うと、ソーシャルメディアへの投稿は、ブランドを構築し、オーディエンスとエンゲージメントを拡大したいすべての企業や個人にとって無視できない、デジタルランドスケープの重要な部分です。ソーシャルメディアマネージャーとしての新人でも、経験豊富な人でも、ソーシャルメディアに投稿する内容と場所のニュアンスを理解することで、オンラインプレゼンスに大きな違いが生まれます。
ソーシャルメディアへの投稿は、単にコンテンツを送信するだけでなく、オーディエンスとのつながりを作ることです。一貫性のあるコンテンツ投稿は、Web 上でアクティブな状態を維持し、オーディエンスのエンゲージメントを高め、すべてのアカウントから高いパフォーマンスを引き出すために役立ちます。
ブランド認知度の強化 -継続的に投稿していれば、すでにあなたから聞いたことのある人々の心にあなたのブランドが残ります。
オーディエンスエンゲージメント: より多くのいいね、共有、コメントにつながるインタラクティブなコンテンツは、相互作用も生みます。
トラフィック生成: 優れたソーシャルメディア戦略は、Webサイトや仮想ストアに多くのトラフィックをもたらすことができます。
SEO のメリット:ソーシャルプロフィールは、現在および将来にわたってSEO のメリットをもたらすライブリンクスレッドです。
ソーシャルメディアへの投稿: あらゆるソーシャルメディアに投稿する次のヒントに従うことで、読者を説得できるだけでなく、ランキングを上げることができます。人々が何を言おうと、ソーシャルメディアはトラフィックを促進します。
1.オーディエンスを知る
誰に話しかけているのかを考え、同じ言葉を話します。宿題をします。オーディエンスの人口統計、お気に入り、および問題点をターゲットにします。オーディエンスとその問題点に訴えるコンテンツを作成します。
コンテンツカレンダーを使用すると、投稿を事前にスケジュールして整理できます。投稿時間のスケジュールを立てると、エンゲージメントを政治的に保つことができます。Trello、Googleカレンダー、特定のソーシャルメディア管理ソフトウェアなどのツールを使用して、これらを合理化します。
画像と動画は、より多くの注目を集め、より良いエンゲージメントを得るための簡単な方法です。ポイント 2 のメッセージとオーディエンスに相関する最高のビジュアル (つまり高品質) を選択してください。Canva や AdobeSpark などのツールを使用すると、美しいグラフィックを簡単に作成できます。
プロのヒント:インフォグラフィック、ミーム、GIF で味付けしましょう。オーディエンスの関心を引き付けましょう!
ハッシュタグを使用する投稿者ハッシュタグを使用すると、投稿が見つけやすくなります。業界でトレンドになっているハッシュタグや関連ハッシュタグを調べて、リーチを拡大するために活用してください。Hashtagify や RiteTag などのツールをチェックして、コンテンツに最適なハッシュタグを見つけてください。
ヒント:ブランドハッシュタグは、ユーザー生成コンテンツとブランドのコミュニティ構築を促進します。
タンゴを踊るには時間がかかります。ソーシャルメディアはこの古い格言に従っているようです。コメントに返信し、質問を投げかけ、会話を開始してください。これにより、関係が確立されるだけでなく、アルゴリズム内での投稿の可視性も高まります。
ヒント:ライブセッション、Q&A、アンケートを実施して、すぐにエンゲージメントを高めます。
6.分析と調整
インサイトの観点からソーシャルメディアのパフォーマンスを常にチェックし、何がうまくいっていないかを判断します。プラットフォームに搭載されている分析ツールから選択するか、Hootsuite や Buffer などのサードパーティツールを使用して、エンゲージメント率、コンバージョンなどの重要な指標を監視します。
ポイント:コンテンツタイプを A/Bテストして、どのコンテンツがオーディエンスに受け入れられるかを調べます。
7.トレンドを常に把握する
ソーシャルメディアのトレンドは急速に変化します。トレンドを把握して戦略を修正します。最新情報を把握する —業界のブログ、ウェビナー、ソーシャルメディアのグループを常に把握します。
簡単なプロのヒント:コンテンツにトレンドのトピックや課題を取り入れます。
Bufferhttps://buffer.com/、Hootsuitehttps://www.hootsuite.com/、FlySocialfly-social.com などのツールを使用すると、投稿をスケジュールして、寝ている間にページが継続的に投稿されるようにすることができます。
投稿やコンサートのパフォーマンスを測定する分析ツールです。Google Analytics、Sprout Social、HubSpot などのツールを使って高度な洞察を得ることも、深い理解を得るための理想的な方法です。
Canva、AdobeSpark、Lumen5 を使用して、アクティビティフィードから注目を集める、非常に魅力的なビジュアルや目を引くビデオを作成します。
SocialBee と Sprinklr は、複数のプラットフォームにわたって単一のダッシュボードからコメント、メッセージ、メンションを監視できる 2つのツールです。
全体として、ソーシャルメディア投稿を完璧にするプロセスには、戦略的な計画とリアルタイムの創造性、そして適切なツールへのアクセスが組み合わされています。本物のつながりとエンゲージメントを促進し、マーケティング目標の達成に役立つ投稿を作成する方法は人によって異なりますが、投稿先を深く掘り下げ、コンテンツをより適切に整理し、より多くのビジュアルを使用し、トレンドを理解することが役立ちます。ソーシャルメディアを活用しましょう。
