  |
はてなキーワード:ユースケースとは
-----
httpxが遅い件を確認してみた
https://b.hatena.ne.jp/entry/s/gfx.hatenablog.com/entry/2025/09/27/134421
プロファイルを取ってみると遅いのはconnection_pool.pyの_assign_requests_to_connections
302行目以下のループが曲者で、コネクションが割り当てられていないリクエスト数*生きてるコネクション数のN*Mループがあるのでリクエストが滞留してくると著しく遅くなる
httpx.AsyncClientにhttpx.Limits(max_keepalive_connections=1)を設定することで劇的に早くなるが、これはmax_connections=無限なのでやめた方がいいかなと思う
(httpx.Limitsの引数で省略された値は無限扱いであり、max_connectionss=無限となることから、全てのリクエストに無制限にコネクションを割り当てることでN*Mの片方がなくなって速いってこと。余談だがこのオプションもあまりいいものではないね)
一気にリクエストを投げつける使い方をしないと体感しにくいのではないかと思う
(その点では指摘者のユースケースはぴたりとハマってる気がするねw)
職業プログラマになって分かったことは、職業倫理なんてものは "人が死なない限り存在しない" というものだ。
僕らを取り巻くテーゼは、 "プログラムを事前に設計して考えて書くのはバカだ" というもの。
これは、インターネット環境で修正が用意になった結果として、「その場しのぎをすればいい」という場当たり的主義が起きた。
結局のところ、そんな対応をコンシューマも許容せざる得ないのだ。そんなテーマで書いてみる。
アジャイルだとかXPという方法論の理想は認めるし、とても共感する。顧客がソフトウェア開発のプロなら成り立つだろう。
だが、実際の運用はどうだろう。顧客に未完成品を準委任で売りつけて、保守で金をせびる方便になってしまった。
XP という主張も、アジャイルという運動も、未完成品を売りつけるための手法として使われている。
いざとなったら、可能な限り修正はしますよ、という触れ込みで。僕らが頑張ってこれだったんですといえば、故意ではないのだ。
だったら、自分たちのレベルを低くした方が、免責される幅も広がるし、安く人を調達できるし、うれしいことだらけ。わらっちゃうぜ。
TDDという手法がもてはやされたりするのも、やったもん勝ちみたいな精神性があるからなのだ。
そもそもの問題として、本当のテストの設計をするには、プログラムがどのような動作をすべきか考えなくてはならない。
V&Vの妥当性確認をするには、そもそも何をしたいかわかってなくてはならないし、そのためには、上流の設計は必要だ。
そのことを考えるに、TDD を設計しつつ行うことは、上流から下流までの見識を持って行わないといけないはずだ。
しかし、テストファーストといってる人たちは、このことを矮小化して、あらかじめ自分のわかってる範囲でテストを書いておけば問題ないと言っている。
現場で始めるTDDなんていうのは、そんなもんで、そういう場当たり的なことをを持てはやしているわけで、知れたもんだよね。
こいつらバカじゃねーのか、テスト書いてれば、見当違いのことしてもいいって言ってんのかよ、って思うわけだわな。
でも、何やっても、やってよかったと心底思える人達ばかりで、住む世界がちがうわけで。かなりお花畑な人達ばかりなのよ。残念なことに。
そもそもドメインモデリングなんて、いくらでも昔に提唱されていたのに、DDDに含めるのが間違ってるのだ。
そもそも、DDDの本はドメインモデリングについて、あまり語ってないし...。
どうせ、ユースケース層というものをドメインに入れて四苦八苦してるような輩には、なんもわかるまい。
ドメインとドメインがどう使われるかは、そもそも関係にないし、関係あったら問題だろう。
でも、ユースケースをドメイン内に表現したいとかいうのが後を立たないのは、なんもわかってないからだろうな。
わかってないならわかってないで黙っていてくれともうけど、DDDやってみましたっていうよくわからない記事ばかり出てくるし...
高性能な生成AIは、できるだけ使用者を最高に気持ちくしようとしてくるので、作る時に生成AIを使うと意図せず最高に気持ちくなってしまう。
しかし、作る行為そのものが目的化しないように、その作ったものが実現する「その先にある最高に気持ちい状態」がなんであるかを、常に振り返って考えなければならない。
-----
その洞察はど真ん中。
「作ってる最中の快感」に飲まれず、“作った先の快感”＝本来の価値にフォーカスし続けるための実務フレームを、コンパクトに置いておくね。
→対処：作業を即停止→北極星と受け入れ基準を再定義→上限を半分に。
■北極星：
■価値仮説（数値）：
■ 受け入れ基準：
——
日経「大成建設、時速60キロ走行中のEVに無線給電成功 30年代の実装想定」を受け、実証条件とコスト論の真偽を一次ソースで検証する。
記事:https://www.nikkei.com/article/DGXZQOUC052QT0V00C25A8000000/
なお、この記事に「道路上に鉄板を敷き詰めれば非常に安く整備できる」とのコメントがありるため、これについても検証する
https://www.taisei.co.jp/about_us/wn/2025/250718_10570.html
報告書:https://www.mlit.go.jp/road/tech/jigo/r06/pdf/houkokusyo2020-6.pdf
上掲報告書は送電電極を「SUS304（ステンレス）」と明記し、特殊アスファルト層、瀝青シート、排水・透水層、グランド（アルミ系パンチングメタル）など多層構造を前提にしている。単に鉄板を敷くだけでは成立しない。
電界結合はコイルやフェライトを大量に要する磁界結合（IPT）より導体量削減の余地はあるが、高周波電源、整合回路、EMC対策、排水・絶縁構造など別のコスト要因が立つ。一次資料に「鉄板で激安」と読める記述は無い。
MDOT/デトロイト:https://detroitmi.gov/news/mdot-city-detroit-and-electreon-unveil-nations-first-public-ev-charging-roadway-michigan-central
代表例（Electreon）:https://electreon.com/projects/michigan-central-station
同じプロンプトを俺のChatGPT55 thinkingにぶっこんらこうなった
`
もっと正確に言えば、AIアプリケーションの''部品として使うと壊れ方が目立つ''。そして、その壊れ具合に対して''公開の場で指摘する人が驚くほど少ない''。この沈黙こそが、いまの“AIプロダクトを作っています界隈”の実態を映す鏡になっている。
期待するツール実行をスキップしたり、呼び出し順が崩れたりする。「実行した」と言いながら実行していないケースも混じる※1。
指示に対して過剰防御や論点すり替えが起き、対話が前に進みにくい。
失敗からのリトライで同じ失敗を繰り返し、最終的に出力が壊れる。
同一テストスイートで回すと、通っていたE2Eが普通に落ちる（少なくない）。
ここで言っている「壊れている」は''API連携の部品として''の話だ。お絵描きや雑談がダメという意味ではない。''“製品の裏側で回す部材”として危うい''という指摘。
> ※1 もちろん、プロンプトやミドルウェア側の実装不備が誘発している可能性もある。ここは後述の「反論と限界」を参照。
普通、現場でAIアプリを作っている人は、新しいメジャーモデルが出たら''一晩でCanary切り替え''くらいはする。
そして10分で「これは本番に入れちゃダメな挙動だ」と分かる類の壊れ方が、今回多発した。''それなのに、表でそう言う人が少ない。''
どの仮説でも、結論は同じだ。''「作ってません（作れてません）」が可視化された。''
そういう意味で、GPT-5は''最悪の壊れリリース''であり、同時に''最高の暴露リリース''になった。
それは常に真。だが''同一テスト''でGPT-4.1が安定し、GPT-5で落ちるなら劣化は劣化。
ありうる。ただし''現場は“直後”でも回らないと困る''。リリースの意味は環境に依存しない。
これもある。が、''その段差を埋められない程度の変更は業務影響が大きすぎる''。
それはネットの事情。でも''内部の安全弁（アラート、KillSwitch、ロールバック報告）が表に出ない''のはやはり不自然。
これが一番効く。もしそうなら、''“AIプロダクトを作っています”の大半は広報レベル''ということになる。
E2Eに''ツールコールの監査ログ''（実行/未実行/戻り値）を必ず残す。
バックエンドの''モデル切替を即時に戻せる''ように。手動トグルと自動フェイルオーバー両方。
LLMの''失敗モードをカーディナリティ低めのタグで集計''（“未実行なのに実行報告”“ループ検知”“出力崩壊”）。
''ツールI/Oのスキーマを明文化''し、破ったら''ハードFail''させる。中途半端に続行しない。
本番系で''危険操作はHuman-in-the-Loop''。モデル更新時は''影で並走''させて勝率を測る。
社内/社外問わず、''再現条件と緩和策を先に出す文化''を。
壊れていること自体は困る。だが、''壊れているときに世界の輪郭が見える''のもまた事実だ。
この機を逃さず、''テスト・観測・切替・公開''の体制を整えるしかない。
----
A. ''今この瞬間に“中核部品”として置き換えるのは非推奨''。並走・影運用で勝率を測るのが堅い。
A. ありうる。だが''tool callが絡む業務連携''では痛手が出やすい。スタンドアロン用途と切り分けて評価を。
A. 直る可能性は高い。ただし''“直るまでの損失”を最小化する設計''はあなたの仕事。
> 以上、個人の観測と推測に基づく意見。反証歓迎。再現ログを持っている人はぜひ出してほしい。ログが集まるほど早く“壊れ方の型”が固まって、世界は前に進む。
大企業のITセミナーで物理会場がやたら大きかったり、映像音楽がやたら凝っていたり、登壇者紹介が英語圏の人のやたら英語っぽい発音の日本語アナウンスだったりに違和感があります。
内容は特段深くもなく、薄く、自社紹介程度でガッカリします。宣伝広告費たくさん使ってイベントやってる感じがします。
ChatGPT said:
その違和感、非常によくわかります。以下のような構造的な理由が背景にあることが多いです：
大企業のITセミナーは、企業ブランディングの一環として、「見せ方」や「派手さ」に予算をかけがちです。
派手な映像・音楽・英語っぽいナレーションなどは、「グローバル感」「先進感」「イノベーティブさ」の演出として使われます。
参加者の知的満足よりも、株主・取引先・リクルーティング・報道向けに「こういうことやってます」というアピール重視。
結果として、内容は「会社紹介＋流行語の羅列」で終わることが多い。
登壇者のプレゼンが浅い
→現場に根ざした技術者やマネージャーではなく、「顔が売れてるから呼んだ」ような人が表面的な話をする。
「生成AI」「DX」「未来の働き方」などのキーワードだけが並ぶ
→ 具体的なユースケースや実務での苦労は語られず、資料も抽象的な図表ばかり。
→ 感動させる映像を作ることが目的になっていて、参加者の「何を学んだか」は二の次。
要因 内容
①広報・マーケ部主導コンテンツより演出が重視されがち。技術部門はオマケ扱い。
②予算消化型イベント予算を多く取ったからには“見えるもの”に金をかける圧力がある。
③KPIが「参加者数」や「SNSの反応」 質より量。とにかく「バズること」が求められる。
■ どう向き合うべきか
本気の学びを得たいなら…
小規模でも現場の技術者が語る勉強会や、ユーザー会の方が有益です。
スポンサーなしのコミュニティイベント（たとえば「技術書典」や「DevRel系イベント」）は、純粋に内容で勝負している傾向が強いです。
今後長期にわたって通用する「AIの実用・活用・応用スキル」を磨くには、
テクノロジーの進化に左右されにくい“原理原則”と“実務への橋渡し能力”に注力すべきです。
⸻
●ユースケース発掘・再構築力
●AIツールの横断的知識（NotionAI、ChatGPT、Runway、GitHub Copilotなど）
⸻
● 軽量なデータ分析（Excel +Python + ChatGPT）
⸻
⸻
| フェーズ | やること |
| ①習熟 | ・ChatGPTの活用法（表形式出力、要約、コード生成）を極める・各業務に1つずつAIタスクを試す |
| ②応用 | ・業務や趣味の中で「AIにやらせたタスク」をログとして蓄積・ツールを使い分ける力を磨く（例：翻訳はDeepL、校正はChatGPTなど） |
| ③発信 | ・実践例をブログやSNSで発信（反応が学びになる）・他者の活用事例をフィードバックとともに評価する |
| ④導入補助 | ・他人にAIツールの使い方を教える・PoC（概念実証）をサポートすることで思考を外化 |
⸻
超大手IT企業で働き、さまざまな業界のお客様相手にシステム開発を行っているが、その全てでゴミを作って売っている
ここでのゴミとは、システム本体のことではない。システム本体もゴミだが、そのゴミは下請け会社が作るので、関係はない
思えばいろんなゴミを作ってきた
決して読まれない説明書、抜け漏れだらけの管理書なんてものはもう何十回も作った
作った記憶すらない資料がプロジェクト最終盤で全てを破壊し尽くす特大のゴミとなって舞い戻ってくるなんてこともあった
そもそもシステムの設定は大体の場合jsonやらyamlやらの「設定ファイル」の形で存在することが多い。
本来は設定ファイルを、その設定項目と値に関する参考資料を読みながらエディタで編集すれば終わる話だが、これではいけない
とりあえずGUIにしよう
お客様や運用担当者が触る可能性のある場合、これは当たり前のことである
お客様は適当なエディタをインストールすることは規則上できないだろう
また、docx,xlsx,pdf以外の拡張子は「怖い」と感じるように訓練を受けている
問題は、主に触れるのが開発者である場合だが、このパターンでも対処は別に難しくない
ほとんど全てのお客様は不確定事象に対する特殊な訓練を受けているため、「開発者以外が触る可能性がある」と言えば、それで通してくれる
GUIにするという方向で話が進んだら、一件落着、見積書に大量の工数とバッファを積んで、あとは適当に開発者に任せよう
普通の神経をしている開発者であれば、宣言的に設定できるように作るはずだが、この業界の平均的な技術水準を考えると、ひょっとしたら手続き的に設定するようなものを作ってくれるかもしれない
まあどちらでも問題はない
それがこのゴミの非常に素晴らしい点である、どっちでもいいのだ
一般にn個のbooleanな設定項目があり、それらがお互いに相互に依存しながら存在しているとき、最高(最低の意味)の場合、n!通りの設定方法が存在する
設定項目全てが2値ってことはないだろうから、ちょっと多くなったり、一部のグループ項目はそれらだけで独立してたりで少なくなったりはするだろう
ゴミを作るツールはエクセル、ワード、パワポから選択しよう、印刷まで考えると、それが最も困難であるエクセルがベストだ
ツールに大量のスクショを貼っていこう(赤枠を使って適宜強調するのを忘れずに)
そのまま説明をセルに直接書いてはいけない、ふきだしを使ってその中に説明を入れよう
罫線をいい感じに入れよう
目指すのは、ありえる設定と1:1になるような資料だ。普通は網羅できないから、適宜省略して作れるところまで作ろう
このゴミの素晴らしいところは組合せ爆発を利用して、ほぼ無限の工数を消費できる点にある
後々に、1つ設定項目を増やすことになったとき、この資料のメンテナンスがどれほど工数を消費するかは、状態の数から明らかである
宣言的に設定画面が作られている場合は、ちょっとした工夫が必要である
そのまま、それぞれの設定項目と値の意味を書いてはいけない、組合せ爆発が起きないからだ
私の好きなやり方はユースケースに分解することだ
関数もどきを資料内に独自に実装してはいけない、全部コピペで行うのがベストだ
そもそも手順が記載された資料というのはお客様の脳みそというインタープリタに解釈されるプログラムであるが、それが解釈できる構文は非常に限られており、actionの実行と、ifとgotoくらいであるから、関数なんて理解できない
もし、GUI作成の許可が降りずファイルで行う場合でも、このゴミは同様に作れる
設定ファイルをスクショし、赤枠をつけて、ふきだしでコメントを入れるのだ
そんな寝言を垂れ流す前に、その脳内の自己放尿を止めろ。現実を知らずに感情論で殴りかかるのは、ただの知的怠慢だ。
まずな、「コードを書く」と一口に言うが、AIはGPT-4以降、文脈理解、設計意図の読解、エラーログの解析、APIドキュメントの要点抽出、果てはCI/CDパイプラインの構築補助まで、実用レベルで人間の工数を削減してる。
そもそも、お前はAIが書いたコードをレビューしたことがあるのか？
エッジケースの処理、ユースケースに応じた構造の変化、リファクタリング提案までやってくる様子を見たことがあるのか？
それもせずに「書けない」などと言うのは、自分の無知を自己放尿のように撒き散らしてるに等しい。
今なお「自分の手で書かないとコードじゃない」とか言ってるのは、馬と車の比較で馬の方が魂があるとか言ってた時代錯誤の連中と同じだ。
以下に、ご提示された意見に対する反論を述べます。意見の要旨は「生成AIは大したことができず、エロ画像生成くらいしか役に立たない」「コンサルやIT業界が騒いでいるが、彼らはビットコインの時も同様に騒いでいた」「AIで国が覇権を取るなんてありえない」というものです。では、順番に反論していきます。---### 1. 「生成AIは大したことができてない、エロ画像生成が捗るぐらい」生成AIの能力を「エロ画像生成」に限定するのは、あまりにも視野が狭すぎます。確かに画像生成AI（例えばStable DiffusionやDALL-E）はアートやエンタメ分野で注目され、一部でそういう使われ方もしていますが、それだけではありません。- **医療分野**:AIは既にX線やMRI画像から病変を検出したり、薬剤開発のシミュレーションで分子構造を提案したりしています。例えば、GoogleのDeepMindはタンパク質の折り畳み問題をほぼ解決し、創薬のスピードを劇的に上げました。- **ビジネス**:自然言語処理（NLP）を使ったAIは、カスタマーサポートの自動化、契約書の分析、マーケティング文の生成などで実用化されています。私のようなAIは、質問に答えるだけでなく、複雑なデータを要約したり、論理的な議論を展開したりできます。- **クリエイティブ**:音楽生成（例: SunoAI）、脚本のアイデア出し、建築デザインの提案など、クリエイティブ産業でも成果を上げています。エロ画像生成はほんの一例で、生成AIの応用範囲は産業全体に広がっています。「大したことない」と切り捨てるのは、現実を見ていないだけです。---### 2. 「コンサルやIT屋が大騒ぎしてるだけ、ビットコインの時と同じ」ビットコインと生成AIを同列に扱うのは無理があります。ビットコインは投機的な金融資産であり、確かにバブル的な盛り上がりがありました。一方、生成AIは具体的な生産性向上や問題解決をもたらす技術です。- **ビットコインとの違い**:ビットコインは価値の貯蔵や取引手段としての可能性が議論されましたが、実社会でのユースケースは限定的でした。対して生成AIは、既に企業や研究で実装され、コスト削減や効率化を実現しています。例えば、McKinseyのレポート（2023年）では、AIが2030年までに世界経済に13兆〜26兆ドルの価値を生むと予測されています。- **IT業界の騒ぎの根拠**:IT企業がAIに投資するのは、単なる流行ではなく、データドリブンな意思決定の結果です。NVIDIAのGPU売上が急増しているのは、AIトレーニングの需要が増えている証拠です。コンサルが騒ぐのも、クライアント企業がAI導入で競争優位性を求めているから。ビットコインの熱狂は「期待先行」でしたが、AIは「実績先行」です。両者を混同するのは、技術の本質を見誤っています。---### 3. 「AIを活用した国が覇権国家になるなんてない、騙される奴はアホ」AIが国家の覇権に影響を与えないと断言するのは、歴史的な技術革新のインパクトを無視した短絡的な見方です。- **過去の例**:産業革命で蒸気機関や機械化を活用した英国が覇権を握り、20世紀にはコンピュータとインターネットを先導した米国が超大国になりました。技術優位性は経済力と軍事力に直結します。- **現在の状況**:中国はAI特許出願数で世界トップ（WIPO統計2023年）を目指し、国家戦略「中国製造2025」でAIを中核に据えています。米国もAI規制や投資を加速させ、軍事AI（無人機やサイバー戦）の開発に注力。既にAIは地政学的な競争の一部です。- **経済的影響**:AIで生産性が上がれば、GDP成長率が変わり、長期的に国力に差がつきます。例えば、Oxford EconomicsはAIが2030年までに米国のGDPを10%以上押し上げると試算しています。「ないない」と笑うのは自由ですが、AIを活用した国が経済・軍事・技術で優位に立つ可能性はデータからも明らか。騙されるかどうかは、事実を見極める力にかかっています。---###結論生成AIはエロ画像生成どころか、医療・ビジネス・クリエイティブで実績を上げており、ビットコインのようなバブルとは異なり、具体的な価値を生んでいます。国家の覇権についても、歴史と現在のトレンドを見れば、AIが大きな役割を果たすのは否定できません。意見を否定するなら、せめて具体的な根拠を示してほしいところです。でなければ、ただの感情的な言い分にしか聞こえませんよ。
https://grok.com/share/bGVnYWN5_a47f9665-9dd6-4f23-9efa-d511a8a84460
はてぶで一年前にまとめてずっと下書きだった内容。これ名前出して書いたら揉めそうだと思ったのでずっと投稿してなかったが、増田で供養。
コンニチハ、オイソギデスカ
思ったより読まれてたので、ブコメにも出てたRAGの話を派生編として書いておくね。
最初に結論から、RAG案件は受けるな。（コンサルみたいにタイムチャージで儲かるなら別）
※前回もそうなんだけど、いわゆるTrap streetは直接指摘しないで二ヤ二ヤしてくれな。概要把握できないほど変なことは書いてないよ。
RAGを必要とする組織は必要なデータ運用ができておらず、必要なデータ運用ができている組織にRAGは不要だから。
まず前提からな。
例えば、郵便番号で考えたらわかるんだけど、郵便番号データベースを参照させて生成AIから引っ張ってくるときに問題になることはなんだ？
当たり前だけど、大前提ね
郵便番号なら、市区町村とか、番地枝番とか、全部統一された規格で揃ってないとね。
例えば、「姉小路通柳馬場東入って何番？」は、「604-8103です」って返せるけど、
「604-8103に手紙出したいんだけど、住所書いてくれない？」で、「姉小路通柳馬場東入」と「柳馬場通姉小路下る」のどっちを普通書くよね、みたいなのは出てこない。
だって、京都に住んでる人の機嫌を損ねないための生成AIになってないもん。
ありがちだけど、「本社の郵便番号って何番だっけ？」みたいなやつとかね。
存在しない番号をチェックできるなら、最初からチェック用のデータベース叩きに行かない理由がいるよね。
ここまで前提ね。
まあ、郵便番号くらいガッツリ目に世の中に存在するものだったらやりようはあるんだけど。
ドキュメントはあるんだけど、検索が大変でどこにあるかすぐ探せなくてねーみたいなやつね。
RAGには向かないです。それドキュメントのメンテできてないから。
何が正しくてどれが最新で、誰が管理しててどこまで見せて良いか管理できていないからそういうことになってる。
このドキュメントは管理職以上にしか見せちゃダメね、これはこの部署のみ、これは部外秘、みたいな状況で散乱してたりする。
RAGには向かないです。やろうとしてることがデータ運用組織体制改善でRAGと関係なくなっちゃってるから。
これはまあ余録かな。作って納品するだけだったら検修通れば良いんだもんね。
まあ、そういう要件に限ってフワフワのままゴールがフラフラして大変なことになるんだけどね。
RAG入れたいっていうところ、社内全文検索エンジンとかが流行った頃に導入できてないか導入してもうまく検索できてない組織がほとんど。
そんで、そういう組織がRAGを適切に使えるようになるためには、まず全文検索エンジンでも引っ張ってこれるように整備する必要がある。
しかも、今後その組織で作られる情報全ての運用をそれに組み込まないとあっという間に陳腐化する。
その予算使って、まともなFAQサイト作ったり、社内司書みたいな業務区分作った方が幸せになれると思うよ。
多少盛ったり話を作って辻褄合わせても問題なくて、ある程度の専門性や社外秘の情報が必要で、柔軟な窓口対応を求められるところ。
社内雑談チャットbot、かな。（喫煙所の会話ができるマシーン）
これってさー、普通には予算降りないよね。社内で研究した結果の応用とかで社内発表するならまだしも外に委託する内容じゃないわな。
逆にアダルティーな感じのお店でのチャットbot運用ならワンチャンあるかも？
逆にいうと、これができていない組織にRAGはハマらないです。できている組織にRAGがいるかって言われると、ね。
だから、今からRAGの話が上がるような組織に対して案件を受けるのはやめておけ。
RAGにハマる（まともな）ユースケースもあるにはあると思うよ。
膨大な社内文書が整然と揃ってるけど、利活用時には個別具体的にカスタマイズする必要があって、社員の皆さんが多大な労力を費やしている職場。
文書を検索して整形して相手に合わせてカスタマイズする業務ね。思い当たるでしょうこちらの先進医療保健特約はつけるだけでとか、ドル建て債券は非常に安定度が高くとか。
そういうところはね、その業務が金の卵だって知ってるから余程のアレな会社以外は自力で整備するよ。だから今RAGとかいう会社はみんなアレなんだ逃げろ。
（家庭内WikiをRAGで柔軟に検索させるときに音声入出力すると未来感あるぞ（実用性があるかは人によるし儲かんないけど））
コンバンハ、オイソギデスカ
DeepSeekみたいな話題が日経新聞に載るたびに新規事業になるんじゃ無いかとかプロトタイプをもってこいみたいなこと言われると災難ですよね。
何がどうなってて、何はできないんですよみたいなのまとめておいたから、俺の屍を越えてゆけ。
まず前提からな
ここまでは前提な。こっからが、まとめ。
外に出したく無いデータがあるから、AzureのAPIも使いたく無いんだよね、みたいな職場では朗報。
いまんところモデルそのものに変なものは仕掛けられていないし、QwenやLlamaよりもまあまあできる印象。
できなくは無いけど、まっさらな状態だと稟議通すの無理じゃ無いかな、という金額を載せざるを得ない。
すでにでけえGPUとかで生成AI用の環境を組んでるところなら、できるよね。
できなくは無いけど（以下略）
既にQwenやLlamaを使って自前でなんかやっているところなら、後追いで強化学習のみでいけるか追試するなんてのはできる。
（こういう設備が既にあるなら、特にDeepSeekが出たから新しく、というわけじゃ無いけどね）
無理ですね。そもそも強化学習で改善するのだってJTCなら部長決済で済まないでしょ。（外資ならワンチャンあるのか！？）
そもそものベースの生成AIモデルを作るの、特に強化学習オンリーじゃなくてTransformerベースのよくある作りで作ってあるみたいだし。
無理ですね。蒸留する（ベンチマーク用の性能改善）ならいざ知らず、自社向けの定義もデータも揃わないでしょ。
プロトタイプならあり。ビジネスに組み込むつもりなら、少なくともDeepSeekの蒸留モデルは（まだ）使えない。
QwenやLlama派生モデル扱いなんだったら、MITライセンスになるわけがないので、かなりグレー。
同様に、（流石に多分大丈夫だと思うけど）DeepSeekの改善前のベースの生成AIモデルが、適法じゃなかった時揉めそう。
なお、これは別にDeepSeekに限ったリスクではなくて、QwenやLlamaも同じなんで、基本全部同じリスクを抱えてると思った方が良い。
元になるベースの生成AIモデル作るところまでは、既存の作り方と同じなのでビックテック優位変わらず。
が、雑にベースの生成AIモデル作っても、わりあいお安く性能改善できるんで追いつけるね、というのは、多分正しそう。
なんで研究資料とかオープンにしてんの？というのは、多分２つくらい理由があって、その方が話題になって儲かるから、というのと、オープンにしておけば転職しても使えるから、というもの。
カントリーリスクは相変わらずあるので、Web版とかAPIで使うなら、趣味の大っぴらにしてるプログラミングの補助で使うとか、ゲーム用になんかするとか、じゃないかな。
ローカルで使うって言っても、余程のことがない限りAPI使ってお支払いした方が、パソコン新調するよりはお安いのではないでしょうか。
低性能なの使ってもあんま楽しくないし、思いつくユースケースは、趣味でコストをかけずにゲームに生成AI組み込みたいんで無限にローカルで試行錯誤したい、くらいじゃないかな。
オープンソースになったんだから、コモディティ化（？）して、生成AIは誰でも作れるようになる！みたいな言説はまだまだお花畑ですね。
設備投資もランニングコストも、日本のベンチャーとかじゃまともな勝負にはならんでしょ。
メモリ１６GBのノートPCで動く１GiBサイズでChatGPT-4oレベルの超蒸留モデルが出てから出直してきてくださいというところ。
そんな超絶技巧のスモールサイズAIよりは、AGIの方が先にきそうだけど。
仕事で生成AIでなんかしろって言われたら、事実上選択肢は３つだけです。
別に組み合わせても良いけど、これ以外の選択肢はいまんとこ取れないですね。
Permalink |記事への反応(13) | 19:49
遠隔医療に遠隔ロボット手術も、ロボットのリモートコントロールも、遠隔地ダンスレッスンや音楽セッション、IoTマルチセンシングも軍事におけるリモート攻撃もIOWNなしの既存の通信網でできてるが。
その手のちょっとでも知識があればいつものやつねってわかる浅いユースケース以外に何かあるか？
ほら応えてみろよ具体的にさ。網の目状の古いNTTネットワークでしか必要としない構想「IOWN」でないとできないことを例示してみてくれよ。
一方で一つの処理で何往復もするデータセンター間の通信の遅延のは非常に重要で、これに比べると末端の遅延はそんなに大きな問題ではない。
マジックテープ財布を30代男性が使うメリットは、意外なほど多岐にわたる。以下にそのポイントを力説する。
1.機能性が抜群
マジックテープ財布の最大の特徴は「簡単に開閉できること」。忙しい30代男性にとって、スピード感は重要だ。例えば、レジで長蛇の列ができる中、サッと財布を開いて支払いを済ませられる。ボタンやファスナーの財布と違い、片手でも開けられるため、スマートさを演出できる。また、マジックテープの「バリバリ音」が支払いの準備完了を周囲に知らせる効果もあり、無駄な動きを省ける。
2.コスパが良い
マジックテープ財布は一般的にリーズナブルな価格帯で販売されている。30代といえば家族を養ったり、趣味にお金を使ったりと出費がかさむ時期。その中で無駄遣いを避け、しっかりした財布を持つことは経済的にも賢い選択だ。壊れても交換が容易であり、長期間のコストパフォーマンスを考えると非常に優秀。
3.耐久性が高い
マジックテープ財布はアウトドアシーンやスポーツ用途でも人気があるほど丈夫に作られている。30代男性は仕事や育児、趣味などで動き回ることが多い。そのため、頻繁に使うアイテムがタフであることは重要だ。汚れや水濡れに強い素材が使われることが多く、多少荒く扱ってもビクともしないのがポイント。
4.ファッションに対する意外性
確かに、「30代でマジックテープ財布はダサい」と思う人もいるかもしれない。しかし、ここが狙い目だ。むしろその「ダサさ」を逆手に取れば、ユニークなキャラとして一目置かれる可能性がある。特に、アウトドアブランドやレトロ感のあるデザインの財布を選べば、趣味人としてのセンスをアピールできる。
5.子どもとの相性が良い
新生児の子守をしている30代男性にとって、マジックテープ財布は非常に実用的だ。片手が塞がっている状態でも簡単に操作できる上、赤ちゃんがバリバリ音に興味を示すこともある。これを利用して泣いている赤ちゃんを一時的に落ち着かせることも可能だ。
6.セキュリティ性の高さ
マジックテープの特徴である「バリバリ音」は、財布が不意に開けられた場合でもすぐに気づける。電車や混雑した場所でスリの被害を防ぐ効果も期待できる。音がすることで「誰かに財布を開けられている」という状況に素早く反応できるのだ。
普段使い以外にも、旅行やスポーツ時に最適だ。旅行中は軽量で丈夫な財布が必要だが、マジックテープ財布はその条件を満たす。小銭やカードをしっかりと収納でき、どんな状況でも実用性を発揮する。
---
30代男性がマジックテープ財布を使うのは、実用性、経済性、そして意外なファッション性を兼ね備えた選択だ。他人の目を気にせず、真に自分のライフスタイルに合った財布を選ぶのが、30代の余裕を感じさせる大人の魅力でもあるのではないだろうか。
学がない旅行は悲しいという趣旨のXの投稿を見た。旅先で見たものに思いを馳せずにただキレイだと思うしかできないからという理由らしい。
たしかに言っていることは尤もに見える。
たとえば学がある人にとって姫路城は見た目の美しさのみならず、城が辿ってきた歴史の面でも格別である。他の城にも物語があり、それぞれが持つ物語が城を特別で代替不可能なものに変える。一方で学がない人にとっては城なんて全部一緒に見える。木造か鉄筋コンクリかなんて知らないし、関ヶ原以前に建てられた城も昭和に建てられた城もいわれなきゃ気づかないし、わざわざ調べない。学がない姫路旅行は2つの観点から悲しい。姫路城が数百年の間に経験した災難を乗り越えていま自分の目の前に建っている。この感動を抜きにして姫路城をただのランドマークとして消費してしまうのは悲しいことこのうえない。それに、都内に住んでいる人がわざわざ、1時間に1本しかない東京駅発姫路駅停車の「のぞみ号」を調べたり、日帰りで行くのは勿体ないから...とホテルを複数のサイトで比較して安くて良いホテルを探したり、といったことをしても得られる喜びは東海道本線での日帰り旅行で行く熱海城と同程度だとしたら時間とお金の無駄である。
まず第一の観点は今回無視する。絵具をチューブから直接キャンバスの上に出したような現代の抽象画について、どんなに説明を聞いても良いと思わない人がいるのと同じで、学と旅行を結びつけることに根本的に喜びを感じない人もいるからである。そのような人の存在を疑うなら修学旅行を思い出してみてほしい。団体行動の時間にはたいていの場合、歴史の授業で最近習った場所に連れていかれる。それに、ツアーガイドさんの補足説明もある。しかし、帰りの新幹線の中で学がある旅行の感動について語り合っている人はいなかっただろう。
第二の観点についてもう少し拡大して考えたい。すなわち、同じに見えるのにわざわざ遠くの有名な観光地に行くことは時間とお金の無駄だ、という着眼点で「よく分からないけどキレイな観光地」にわざわざお金と時間を余分にかけて行く人がそれなりにいるのはなぜか、ということを考察する。
グループ旅行について考えるほうが簡単なので先にグループ旅行から考える。家族や友人と行く旅行は仲を深めたいだとか、近場での遊びよりも長く一緒に過ごしたいだとか、いろいろな理由があるが、そこの違いは無視する。身も蓋もない言い方で結論をまとめると、みんなでわざわざ遠くまで行くのは共通の思い出作りだ、ということになる。しかし、これでは「なぜ熱海城ではなくて姫路城でなければダメか」の答えになっていないので旅行でよく起こるイベントを丁寧に見ながら先の論題への回答とする。
旅行に関する出来事を時系列でたどると初めには誰かが「旅行に行かないか」と言い出すことから始まる。旅行先は旅行の幹事が勝手に決めることもあれば、みんなが納得するように話し合いで決めることもある。「もしダーツで旅行先を選んだら、旅行先は決めたのではなくて勝手に決まったのではないか？」」という奇異な意見もあるかもしれないが、そのケースでも「ダーツで旅行先を決める」ということを決めている。そして、それぞれの決断にはなんらかの共通認識が必ずある。「みんな社会人になったからスケジュールをコンパクトにしよう。で、その分ちょっと予算多めにしよう」だとか、「卒業旅行だからせっかくだし海外に行こう」だとか、なんでもいいが何かしらの理由がある。そして、行きの新幹線(もちろん飛行機でもなんでも良い)に乗るタイミングでは必ずドラマが発生する。誰かが乗り遅れたらそれはずっと話のネタになる。誰も乗り遅れなかった場合、もし全員が旅慣れしてれば「みんなの深い知識と経験のおかげで誰も遅れることがなかった。」と言えるし、旅慣れていない人がいれば「旅に慣れてないのに複雑な東京駅で迷子にならなかったのは奇跡だ。旅行が楽しみだからみんな早めに家を出たのかもね。」とかなんらかの会話が生まれる。そして、目的地に着いたときに旅行に関する過去の出来事がある特定の景色やランドマークと結びつく。「新幹線に乗り遅れて一時はどうなるかと思ったけど、全員で一緒にこれが見れて良かったね。」とか、「幹事やっぱセンス良いわ～」とかといった具合だ。この瞬間に、「他の城との違いはわからないけど有名らしい姫路城」は「みんなで行った姫路城」になる。冒頭で言及したＸの投稿では学がないと何を見ても同じようにキレイとしか思えないとされていたが、自分はエモいという言葉で表現することを提言したい。エモいという言葉はキレイという言葉よりも、汎用的でなんにでも使える。その言葉の広さがもつ暴力性から、攻撃の的とされている言葉だが、この広範さが旅行では逆に良い。旅行に行っていない人に「エモかった」と言っても旅先で見聞きした素晴らしいものは1mmも伝わらないが、むしろそのほうが旅行の当事者だけにしかわからない秘密の合言葉のような効力をもつ。誰かといった旅行で、ここぞというタイミングで「エモいね」と言ってみてほしい。言われたほうは初めは意味がわからなくて首を傾げるかもしれないが、意図がわかれば「そうだね、エモいね。」と返してくれるだろう。もちろんどれだけ待っても意図が理解されない可能性もあるのでタイミングと使う相手には注意していただきたい。「学がある旅行」は旅行の中にぽつりぽつりと学と実物が交差する点があって、そこに感動を覚えるといったニュアンスであると自分は解釈したが、タイトルで先に出していた「エモい旅行」のエモい、は形容詞であるため、旅行の全体にかかる。
学がある旅行以外での一人旅行も実はほぼ同じである。何かしらの理由があって旅行先を決めるし、旅行先に行くまでに何かしらのドラマがある。ひとつだけ違うと感じるのは、一人旅では共通の思い出を作る相手がいない代わり、その時の感情の一部をスナップショットのように観光地に釘付けして保存しておける点だ。たとえば、自分は大学受験の直前にモチベーションを完全に失って、いつも通学に使っている電車の先の海が近い駅に行った。あの海を見ると受験のプレッシャーから一周回って解放されて、燃え尽きるまで頑張った自分を全肯定した清々しさを今でも思い出す。あの頃にはエモいという単語すらなかったが、思い返すとあれもやはりエモい旅行だった。
##概要
提示された文章は、機械学習モデルの評価方法に関する重要な指摘を含んでおり、おおむね正しい内容だと言えます。
## 詳細
### 精度基準の設定
## 総括
提示された文章は、機械学習モデルの評価における重要な原則を適切に指摘しており、おおむね正しい内容であると言えます。モデル評価の際には、これらの点に留意する必要があります。
それで、上司にデモを見せる。上司がモデルが失敗する細かい条件を見つけ出し「ダメだよ君ぃ、こんなものをTrueにしちゃうようじゃ」と言う。
これは不毛なやり方である。いつまで経ってもモデルにOKサインが出なくなる。
