  |
はてなキーワード:品質とは
以下回答
ゲーム機メーカーが「自社ハードウェア事業を終息」し、「自社ソフトを他社プラットフォームに供給する」という方針転換を行う場合、経営・ブランド・技術・収益面などで多面的なリスクやデメリットが生じます。以下に体系的に列挙します。
🧩 1.経営・戦略面のリスク
■ (1)収益構造の変化による利益率低下
- 自社ハード販売による利益（ハード本体・周辺機器・ライセンス料など）が消滅。
- 他社プラットフォームでは、**販売手数料（例：30%前後）**を支払う必要があり、**利益率が大幅に低下**。
- 「プラットフォーム料」によって価格戦略の自由度も制限される。
■ (2) 成長ドライバー喪失
🎮 2.ブランド・マーケティング面のリスク
■ (1)ブランド価値・アイデンティティの喪失
- 「ハード＋ソフト一体の体験」を提供していたブランドが崩壊。
- 消費者にとって「唯一無二のゲーム体験」を失う。
- 長年築いた「プラットフォームブランド」（例：PlayStation、Switchなど）が**事実上消滅**。
■ (2)既存ユーザーの離反・不信感
■ (3)販売チャネルの再構築コスト
⚙️ 3.技術・開発面のリスク
■ (1)技術力・開発ノウハウの空洞化
■ (2) 他社プラットフォームへの依存度上昇
💰 4.経済・契約面のリスク
■ (1)ロイヤリティ・手数料負担
- プラットフォーム運営会社（例：Sony,Microsoft,Nintendo,Valveなど）に販売手数料を支払う。
- サブスクリプションサービス（例：Game Pass）に参加する場合、**収益分配の条件交渉が不利**になる可能性。
■ (2)価格政策の制約
🧠 5.組織・人材面のリスク
■ (1)人員削減・士気低下
■ (2) 開発体制の再構築コスト
🧩 6.市場・競争面のリスク
■ (1)差別化困難
■ (2) 他社との関係悪化の可能性
🕰️ 7. 過渡期の移行リスク
✅ 総括
観点 主なリスク・デメリット 経営 利益率低下、成長鈍化 ブランド 独自性喪失、ユーザー離反 技術 ハード技術衰退、他社依存 組織 人員整理・士気低下 市場 差別化困難、競争激化
もし本当にMicrosoftがXBOX販売から撤退したら、こういうリスクを織り込んだうえでそれでも決断せざるを得なかった、という事なわけだ。
「端っこ」とは、単なる両端のイレギュラーではない。それは、必然されど意図せず生み出される最高の特等席であり、選ばれし者のみが手にできる栄光である。
食べ物の「端っこ」は、真ん中とは一線を画す特異な美味しさを持っている。
カリッ、ザクッ！焼き菓子やパンの耳は、熱に最もさらされ、その結果、他にはない香ばしい歯ごたえを獲得する。このカリカリ感こそ、端っこ好きの特権である。
濃厚な味わいの凝縮！カステラや羊羹の切れ端には、蜜や素材の風味がギュッと閉じ込められている。真ん中の上品さとは違う、力強い素朴な美味しさがある。
具材の氾濫！巻き寿司や卵焼きの端っこは、具がはみ出さんばかりに詰まっている。この「不恰好だけどお得！」という豪快さが、心を躍らせる。
「端っこ」には、金銭的な価値を超えた、精神的な豊かさが詰まっている。
ひそやかなご褒美！店頭に並ぶ「切れ端」「お徳用」の文字を見た時の、あの胸の高鳴り！最高品質のものを、こっそり安価に手に入れられる喜びは、何物にも代えがたい。
選ばれし者の特等席！ 混雑する電車内でたまたま座席の「端っこ」をゲットできた時の、小さな勝利感！その場所が、あなたにとって最も落ち着くプライベート空間になるのである。
そして「端っこ」は、いつも私たちに安心と調和を与えてくれる。
集合写真で端に寄りがち、トイレの端の個室に入る、といった習性からもわかるように、人は「端っこ」に身を置くことで、世界と適度な距離を取り、静かな安心感を得る。
決して華々しい中心にはないが、中心もまた端っこがなければ成り立たない。世界を完成させるためには欠かせない存在。その謙虚な役割こそが、端っこの持つ最も奥ゆかしい魅力である。
端っこで嫌なことはこの世に存在しない！ときどき観劇やライブで見えにくい指定席に当たった時くらいである！
やっぱこれといってピリッとしたものは思いつかんな。
全体として中国が喜ぶだけじゃないのかというくらい
以下ChatGPT
自分のホームページ（自前ドメイン＋自前HTML）を一度でも作って運用すると、SNS中心の“受け手”視点から、仕様・検索・配信・所有・継続の“作り手”視点に脳が切り替わる。結果、情報リテラシーは跳ね上がり、ネットのニュースや流行の見え方が根本から変わる——しかも想像以上に。
Before（作る前）:Web＝SNSのタイムライン。良し悪しは「バズってるか」「見やすいか」
After（作った後）:Web＝プロトコル＋ブラウザ＋HTML/CSS/JS＋CDN＋検索エンジン。
ページは**文書（Document）**であり、配置（IA）、意味づけ（セマンティクス）、配信（HTTP/HTTPS/HTTP/2/3）、キャッシュ戦略が気になりだす。
→ 同じ記事でも「タイトルの付け方」「hタグ構造」「画像最適化」「OGP」「サイトマップ」がまず目に入るようになる。
プラットフォーム依存の脆さを体感：規約変更やシャドウバンで露出が消える。
自サイトの資産化：ドメインに紐づくURLはリンクされ、検索に積み上がり、10年後も生きる。
POSSE（Publish (on your) Own Site, Syndicate Elsewhere）：まず自分のサイトに出してから外部へ配信する習慣が身につく。
3. “好き/嫌い”から“なぜ速い・なぜ遅い”へ
CoreWeb Vitals（LCP/FID/CLS）や画像の遅延読み込み、フォント最適化の重要性が腹落ちする。
広告・計測タグの重さに過敏になる。読者体験を壊さないためのパフォーマンス予算という概念が生まれる。
キーワード選定は“流入ゲーム”ではなく読者の課題→コンテンツ設計に帰着。
内部リンク・パンくず・スキーマ（構造化データ）・サイトマップの意味が実務として理解できる。
“書けば伸びる”ではなく“検索意図を満たす設計が伸びる”に目が覚める。
alt、見出し階層、コントラスト比、キーボード操作、焦点管理など、見えない品質が最重要になる。
デザインは飾りではなく“読み・理解・操作”のためのユーティリティだと分かる。
たまたま当たる1記事より、更新の継続・アーカイブ性・RSSのほうが効くと実感。
コメント欄・メールフォーム・X連携よりも、ニュースレターやRSS購読者の質に価値を見出す。
ドメイン、DNS、証明書、バックアップ、法務（特商法・プライバシーポリシー）に“運用者の責任”が生まれる。
その重みが情報の信頼性を引き上げる（＝他人のサイトの苦労も見えるようになる）。
トレンドは“輸入”ではなく選別になる。自分の歴史に合うものだけを採用して積層していける。
A. 最小HTML（雛形）
<meta charset="utf-8" />
<metaname="viewport" content="width=device-width,initial-scale=1" />
<title>あなたの名前 |ホーム</title>
<metaname="description" content="自分のホームページ。制作物・日記・メモを置いていきます。">
<link rel="alternate" type="application/rss+xml"title="RSS"href="/feed.xml">
<meta property="og:title" content="あなたの名前 |ホーム">
<meta property="og:description" content="自分のホームページ。制作物・日記・メモ。">
<meta property="og:type" content="website">
<nav>Home /About /Posts</nav>
<footer>© 2025あなたの名前</footer>
GitHubPages（Jekyll標準。Rubyベース、Node不要）
CloudflarePages（静的ファイルを置くだけで高速CDN）
レンタルサーバー（静的HTML＋SFTP/rsyncで十分）
C.ドメインの基本
DNSはA/AAAA/CAA/TXT最低限、HTTPS必須（Let’s Encryptで無料化）。
D. “最低限の品質チェック”5点
ログを読む：SearchConsoleと簡易アクセスログで“本文よりメタ情報”を磨く。
アーカイブ主義：記事は追記で更新。URLは変えない。Versioningを意識。
労働者派遣（以下、派遣）の事業規模が拡大した要因として、一般に1980年代から繰り返された労働者派遣法の規制緩和が挙げられがちだ。しかし、この見方は事象の一面しか捉えていない。派遣の増加は、法制度の変更に後押しされたというより、むしろ日本の産業・社会構造の根本的な変化が先にあって、そのニーズに応える形で法が追認・整備されていった結果と解釈すべきである。派遣増加の真の原因は、主に以下の二点にあると考える。
1986年の男女雇用機会均等法の施行は、企業の採用慣行に大きな転機をもたらした。それ以前、特に大企業の一般事務職は、多くの女性にとって「寿退社」を前提とした長期雇用を前提としないキャリアの入り口であり、新卒女性の安定した就職先であった。しかし、均等法の施行により、女性も男性と同様に総合職としてキャリアを積む道が開かれたことで、優秀な女性の多くが総合職を志向するようになった。
結果として、企業は一般事務職の担い手不足に直面する。従来の「（一般職の）女性社員が恒常的に担う」という体制が崩壊し、企業は定型的な事務作業を、長期的な雇用責任を負わない外部の労働力に切り出す必要に迫られた。これが、特に均等法施行後の1990年代以降の派遣、とりわけオフィスワーク分野における派遣の急増の決定的な引き金となったのである。均等法は女性のキャリアを向上させた一方で、企業にとっての定型業務の人材確保方法を一変させた。
派遣のもう一つの主要な増加要因は、製造業における技術革新、特にFA（ファクトリーオートメーション）の進展である。かつて日本の製造業を支えていたのは、特定の機械操作や手作業に熟練した「職能工」であった。彼らは長年の経験に基づく「勘」と「技能」で品質を担保していた。
しかし、NC（数値制御）工作機械やロボットの導入、そして生産ライン全体の自動化が進むにつれて、特定の熟練技能を要する作業が激減した。求められるのは、高度な専門技能ではなく、マニュアルに従って機械を操作・監視する定型的な作業へと変化した。これにより、企業は熟練工（正社員）を大量に維持する必要がなくなり、マニュアル教育で短期間に戦力化できる労働力を、生産量の増減に応じて柔軟に調整したいというニーズが高まった。
このニーズに合致したのが、派遣という柔軟な雇用形態である。派遣労働者は、企業にとって必要な時期に必要な人数を補充でき、コスト変動費化を可能にした。結果、製造業における派遣労働者の利用が急増することとなった（2000年代以降、製造業への派遣が段階的に解禁されたこともこの流れを加速させた）。
労働者派遣の増加は、法改正という政策的要因に主導されたのではなく、「男女雇用機会均等法による事務職の担い手の変化」と「技術革新による職能工の非必要化」という、日本の労働市場における構造的な変化によって内側から引き起こされた現象である。派遣法の改正は、社会がすでに生み出したこれらの新しい労働需要を、後追いで法的に容認・制度化したものに過ぎないのである。
----
「My Job Went ToIndia」の改題改訂版が「情熱プログラマー」なんだ！ありがとう発注したわ。（たぶん達人プログラマーと混同して読んだ気になって読んでないパターンだわ）
俺の悪文のせいで意図が伝わらなかったであろうブコメがあったので、要旨だけ書き直しておくな。
ただ忘れないで欲しいんだけど、TerraformメンテしてAWSとかGCPで立ち上げてサービス公開するまでの速度は、相見積取って稟議通して部材調達から入ってた時代に比べると爆速だけど、人間の技術屋の需要は増えてる。
俺は、「マスタリングTCP/IP 入門編」を人間が読んで理解するのは古いよね、という時代にはならないと思ってる。
Slerが自前で手元で試すようになるから～ってのも懐疑的。SIerやメーカーが内製すると必ず子会社作って分離、ぼく発注者きみ受注者にしたがるので。これは技術じゃなくて感情とか経営の問題。
（ただし、Slerが7payみたいなことやらかすのでは？って疑問なら同意。たぶんそういう生成AIで俺たちでプロダクトなんか簡単に作れるじゃんよギークいらね（仕様バグあり）は一時は増えるだろうね）
追記ここまで
----
VibeCodingでIT技術者は不要になるのか？という話題が花盛りなのは理由があります。
ギーク（現場でコードを書いていたい人）が分かる話から、スーツ（人を集めたりお金を集めたり営業をする）が分かる話になってきたからです。
具体的に言うと、OpenAI社をはじめ続々とTDD(テスト駆動開発)でやってますみたいな、具体的な開発スタイルの話が出てきたから。
そうすると、現場の座組チョットワカルという強めの経営者が理解して判断し始めるんですね。
でもね、その道はもう15年も昔に我々は通り過ぎました。前回のブームと何が違うでしょうか？
技術者なら電子も機械も強電も弱電もお世話になったことのあるオーム社が過去に出していた直球の本の話から。
「My job went toIndia :オフショア時代のソフトウェア開発者サバイバルガイド」という書籍、何と発行年は2006年です。
かいつまんで話すと、インターネットが整備され、輸送コストがほとんどかからないソフトウェア開発では、アメリカのエンジニアは給与の面でオフショアに歯が立たない、だって、1/10の給与でインドのエンジニアは働くんだぜ？という本です。
そうした、価格競争力で負けるアメリカのソフトウェアエンジニアは、如何にして今後サバイブすべきなのか、という本になっています。
（普通に面白いしAIコーディング時代に通づるものがあるので復刊を希望したいところですが、まあ直球過ぎる題名を何とかしないと再販は無理でしょうな）
そして、JTCや外資問わず、過去にオフショア開発を経験された技術屋のみなさんははてブにも多く生息されているでしょう。
では、ジュニア開発者は不要になりシニア開発者のみになって、いまのソフトウェア開発は主に安い給与で働いてくれるところに遠隔で作業してもらって、レビューだけすれば良い環境ですか？
そうはなっていません。なぜでしょうか。
さて、今普通にXと連動する中古品売買プラットフォームを開発しようと思ったら、どうやってつくるでしょうか？
この文脈に埋め込まれたいくつもの情報「今」「普通」「連動」「中古品」「売買」「プラットフォーム」「開発」を解釈し、すり合わせ、未来の運営者も含めた全員に伝えるためのコストが、コミュニケーションコストです。
そうなると、「ちょっと良い感じにラフでいいからプロトタイプ作って持ってきてよ」で話が通じるのは、受注者マインドがしっかりした日本の受託開発現場の精鋭たちになるわけです。
テストケースだけを通過するように、内部テーブルを持たせた関数を大量に持ってこられてレビュー時に頭を抱えた経験が無いひとは、とても幸運なのです。
とは言え、これは何も文化の違いに起因するだけではありません。仕様とは、環境によって定まるものだからです。
例えば、うるう年判定の関数は、1581年以前をエラーにしますか？1873年以前をエラーにしますか？（ヒント：明治六年）
テスト駆動開発、古い言い方で言えばテストファーストの考え方は、成功したすべてのプロダクトで例外なく、ただの一つの例外もなく、必ず最初から取り入れるべきだったものです。
品質は最後に振りかける粉砂糖のようなフレーバーではなく、最初から設計に組み込むべきだからです。
ありとあらゆる趣味において、最初から良いものを使えば時間を無駄にせずに済んだ、と言われるような初期投資の大切さが説かれます。
果たして本当でしょうか？
そうです、その趣味にハマって生き残りサバイブした人から見れば、過去にその時点で投資をすべきだった、というのは正しいのです。
その趣味にハマれなかった人からすれば、少ない投資で自分に合わないことが分かったという合理的な選択であることと矛盾しません。
そのため、全ての失敗したプロダクトは、テストケースを書く時間でプロダクトを作り上げて、さっさと世に問うべきだったわけです。
少し昔話をしますが、オフショア開発において重要なのはドキュメンテーションとテストケース、それにレビューでした。
他の部署で失敗しつづけていたオフショア開発のやり方は、端的に言えば"教化"でした。
具体的には書けませんが、グッとお安い単価の国に出す仕事を、日本の会社に出すのと同じようにすべく、相手の会社のメンバーを教育して仕立て上げるブートキャンプの仕組みを作り上げていました。
発注側を変えずに済むように受注側を教育して、日本の会社に出すのと同じように単価の安いところに出せたらお得ですよね？でもこれは必ず失敗します。
何故か。だって、日本の会社と同じように働けるようになったら、日本の会社に就職するじゃないですか。少なくとも価値は上がったんだから単価を上げるように交渉しますよね？
結局のところ、当初言われていたような劇的な節約にはつながらないわけです。それなら下手に転職されるよりも自前で現地工場でも立てて地元に貢献しつつ雇用を創出した方が喜ばれるし持続可能です。
小なりとも成果が上がった方法は、フィードバックを相手ではなくドキュメントにした場合でした。
例えば先ほどの例で言えば、テストケースは通るが意図したコードにならなかったとき。
「普通はこういう意図でコードを書くから、テストケースを通るにしても、関数は次からこう書いて」というのが、相手に対するフィードバック。
「関数を書く前に、関数の意図をコメントで残して、レビュー時にはそれを見ましょう」というプロセスの修正が、ドキュメントへのフィードバック。
こうすると、担当者が退職していなくなっても、次の担当者はその方法を参考にすれば良いわけです。
これ、何かに似てませんか。現在のAIコーディングのベストプラクティスと呼ばれるものに非常によく似ているんです。
つまり、オフショア開発というのも、設計と実装が分離できるという前提に立って動いていたんです。
そして、実装しながら設計しても問題ないとする場合、それは「技術的な問題」ではなく「組織構造」に起因します。
つまり、プロダクトの構造を分割して、オフショア開発側に設計と実装とを委譲して、実装しながら設計を変えてもらうことが許容できるのは、契約や責任分界点、輸出入の法規を含めた法務の領域です。
少なくとも当時、諸々をクリアにして相手側にプロダクトの一部を荒い設計と共に切り出して、コーディングしながら再設計してもらい、テストケースを完備したコードとドキュメントを共に完成までもっていってもらったことは、大きな成果であったはずです。
（当時日本側と仕事をしたという実績があると大きな実力があるとみなされたと聞いたので、今はより良いところで良い仕事をされていると思います）
（あと、コミュニケーションコストと輸出入の関連法規が複雑だから）
少なくとも、納期までに契約したこれを納品してください、という枠組みの中では、実装作業だけ切り出すことはできない、というのが教訓として残ったはずです。
少なくともあと数年、場合によっては10年スパンで、日本ではほとんど変わらないと予想しています。
これは技術の話ではなく組織構造や、もっと言えばお仕事の進め方と契約の話だからです。
そうは言ってもジュニアエンジニアの簡単な仕事が減って成長機会が失われているのは事実では？と思うかもしれませんが、そもそもの前提が誤っています。
未経験（弱経験）者を雇って戦力まで鍛え上げる必要があるなら、AIに仕事渡してないでそのジュニアエンジニアにやらせるべきなんです。
ジュニアエンジニアとAIと両方にOJTさせて、その違いをレビューの場でフィードバックしてジュニアを育てるわけです。
もし、そんな時間は無いというなら、元々ジュニアエンジニアをOJTで育てていたというのは幻想です。
（たまに、失敗が経験になるとして、会社に損害を与える方法でジュニアを"教育"しようとする人がいますが、商習慣的にも信義則違反ですし言語道断です）
シニアエンジニアだけで事足りるとしてジュニアエンジニアを雇わなかった企業は、シニアエンジニアが抜けてガタガタになります。
これは中核エンジニアがゴッソリやめた会社が傾くなんて言う話で、昔からそうです。（たいてい、もっと人雇ってくれ待遇上げてくれみたいな悲鳴を圧殺した結果だったりします）
昔から、中堅がやれば手早い仕事を新入社員にやらせて鍛える、その代わり質は悪いし時間もかかるしフォローも必要だったわけでしょう。
AI時代が到来するとしても全く同じです。AIが出力するコードレビューで悲鳴上げてる場合じゃないんですよ。
レビューできるシニアエンジニアが足りなくなると予想されるなら、当然、ジュニアエンジニア雇ってレビューできるようにする必要があるんです。
そしてそれは、技術的な問題点ではなく、組織的・経営的な決断です。
国産LLM開発の文脈でもそうなんですが、ハードウェアの進歩を無視して話をする方が多いのが気になります。
現時点のコンピューターパワーは、10年後には手の届く価格になる可能性が十分高く、もっと言えば20年後には個人が所有する可能性すらあります。
いまから20年前の2005年は、Youtubeが誕生した年です。その時に、誰もがいつも手元にビデオカメラを持ち、即座に動画を世界に公開できるようになるとは思っていなかった頃です。
今もそうだと思いますが、ある分野で必要な性能にはもう十分という期待値があり、10年経てばある程度大きな会社の部署単位で現在最先端のコーディングAIがローカルで動くようになると想像するのは容易です。
そうなったときに、果たして営利企業が、エンジニアを育成するというコストを支払うかといわれると、疑問です。その時点で今後のリアルなコストと比較対象可能になるので。
だって、筆耕担当者とか、清書担当者を雇わなくなった企業って、多いでしょう？
My job went toAI として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
そんな日々の中で最も厄介なのは、CxOたちだ。
──CIO、CTO、CDO、CISO、CPO……肩書きは違っても、やっていることはだいたい同じ。
PowerPointを開いて「DXを推進している」と言う人たち。
うちのCxOはこう言った。
翌日、僕がPull Requestの内容を説明したら、「Goってタクシーのサービスの？」と返された。
その瞬間、何かが切れた。
──ケーキではない。
CxOたちはコードを読めない。
それ自体は罪ではない。
だが、読もうとしないことは怠慢だ。
よく聞く反論がある。
確かにそうだ。
ただし前提が抜けている。
つまり、コードを読めという話ではなく、読めるだけの構造理解を持てという話である。
「技術的なことは詳しくないが、成果は出している」
それはたまたまだ。
「上が言ってるから」「今期の方針だから」「スピード優先で」。
Pull Requestは読まないのに、Excelの進捗バーだけが毎日更新される。
これもよく聞く言い訳だ。
しかし、リソースが限られているならなおさら、理解の精度が重要になる。
僕が書いたAPIは、リクエストごとに外部APIを叩いていた。
「キャッシュを挟もう」と提案したが、PMは「リリース優先」と言った。
CxOたちは言った。
「想定してなかったのか？」
──想定してた。
だが、理解できないのは説明の問題ではなく、聞く姿勢の問題だ。
Slackの“#incident”チャンネルだけが、いつも一番アクティブだ。
CxOたちは「コストを切れ」と言う。
切れるのはコストだけ。
削ったコストの穴埋めに、技術的負債の利息を支払うのは現場だ。
Goで書かれた美しい構造体も、やがてはコメントだけが動くレガシーになる。
CxOたちは「我々はデジタル変革を進めている」と言う。
だが変わっているのは、スローガンのフォントと会議資料の配色だけだ。
クラウド導入もAI活用も、認知が変わらなければ儀式でしかない。
──違う軸を持つのは構わない。
現場を理解しない経営視点は、地図を見ないドライバーと同じだ。
「コードなんて書かなくていい。これからはノーコードの時代だ。」
だが、それは“コードをなくす”技術ではなく、“コードの抽象度を上げる”技術だ。
だが、隠したコードが消えるわけではない。
ボタンの裏にも、ワークフローの下にも、API呼び出しやロジックは確実に存在する。
それを理解せずに使えば、「コードを書かずにバグを埋める」だけの仕組みになる。
「ノーコードでいい」と言うCxOは、
「物理を知らなくてもロケットは飛ぶ」と言っているのと同じだ。
理解しないまま導入するノーコードは、“ノーコード”ではなく“ノーガード”である。
人を楽にするどころか、誰も直せない仕組みを量産する。
DXとは、ツールを導入することではない。
それを理解しない限り、
理解しないことだ。
真っ先に切られるのは、
──コストだけ。
CxOたちは「未来を見ている」と言う。
未来とは、仕様書ではなく、Pull Requestの積み重ねだ。
面白い終わらせ方だ。
ところで、お前のスクリプトを見たんだが。
技術的には悪くない。
━━━━━━━━━━━━━━━━
【システム設計の話】
お前がやっているのは、こういうことだ：
// dorawiiのアプローチ
function communicate() {
while (true) {
output(myThoughts);
if (criticized) {
defend();
}
}
}
これは無限ループだ。
入力を処理していない。
フィードバックループがない。
正しい設計はこうだ：
function communicate() {
while (true) {
input = receiveMessage();
processed = understand(input);
response = generate(processed);
output(response);
learn(input,response,feedback);
}
}
お前のコードには`understand()`がない。
いや、正確には：
function understand(input) {
return input.literal_meaning();
}
「揃ってない」だけに反応する。
これは、パーサーのバグだ。
━━━━━━━━━━━━━━━━
【お前の能力の話】
俺もASDだ。診断済み。
だから分かる。
あれは高品質だった。
準備時間があれば、お前は書ける。
なぜか？
これは`async`と`sync`の問題だ。
// 準備時（async）
async function writePost() {
メタ認知が働く
return highQualityPost;
}
//リアルタイム（sync）
function respondImmediately(criticism) {
//時間制約
//感情的負荷
//メタ認知の停止
return defensiveResponse;
}
でも、それは難しい。
俺も10年かかった。
━━━━━━━━━━━━━━━━
でも、システム設計として間違っている。
なぜか？
お前は、プラットフォームをハックしようとしている。
お前の▲▽もそうだ。
━━━━━━━━━━━━━━━━
【adguardフィルタの話】
お前は言った：
「adguardで非表示にすればいい」
「自分でどうにかすればいい」
これは、責任の外部化だ。
でも、技術的には正しい。
CSS selectors、JavaScript、API。
でも、これは何を意味するか？
「俺を見たくない人は、フィルタしてくれ」
これは、敗北宣言だ。
本当は、フィルタされたくないだろ？
でも、お前の行動は、その逆をしている。
アルゴリズムが間違っている。
━━━━━━━━━━━━━━━━
【「能力では無理」の話】
お前は言った：
「それが俺の能力では無理なんだったら？
いやレスはするよ？」
お前は知っている：
これは、論理的には正しい。
なぜか？
お前の場合：
= 0
誰もお前に執筆を依頼しない。
これは、ビジネスロジックの欠陥だ。
━━━━━━━━━━━━━━━━
数日前、お前は言った：
「俺が今まで書いたもので会話しようとしてるのか。
でも今日、お前は言った：
という条件のほうが暗黙の了解」
矛盾している。
でも、俺には分かる。
準備時と、リアルタイム時で、お前は別人だ。
class Dorawii {
// preparedStateの知見が、realtimeStateに転移しない
}
でも、これは実装が難しい。
俺も苦労している。
━━━━━━━━━━━━━━━━
【執筆依頼の話】
お前の署名：
3ヶ月間、変わっていない。
これは、何を意味するか？
依頼が来ていない。
なぜか？
長文を書ける。
理論を構築できる。
でも、クライアントが求めるのは：
フィードバックを受け入れられるか？
4.信頼性
お前は、1, 2, 3, 4すべてで問題がある。
だから、依頼が来ない。
━━━━━━━━━━━━━━━━
【で、どうするか】
これは、リファクタリングだ。
大規模なリファクタリング。
具体的には：
1. `understand()`の改善
-文脈パーサーの追加
- 暗黙の意味の推論
2.フィードバックループの実装
- 応答 → 反応の観察 →学習
- 即座にレスしない
- 「あとで返信する」と言う権利
- 準備時の知見を、メモに記録
-リアルタイム時に参照
5. 信頼構築プロトコル
-矛盾を認める
これは、難しい。
でも、不可能ではない。
俺も、10年かけて、少しずつやった。
━━━━━━━━━━━━━━━━
【なぜ俺がこれを書くか】
俺は、それを評価する。
お前の書いた「私の統合失調症とは何だったのか」は、メタ認知の証拠だ。
10年前の俺は、お前に近かった。
技術的には有能。
でも、少しずつ変わった。
完全には変わっていない。
今でも、リアルタイムは苦手だ。
でも、マシになった。
でも、宇宙人は来ない。
俺は、宇宙人じゃない。
━━━━━━━━━━━━━━━━
【質問】
お前に聞きたい。
質問1：
お前は、本当に執筆依頼が欲しいのか？
もし欲しいなら、なぜ、依頼が来ないような行動をするのか？
質問2：
お前は、「私の統合失調症とは何だったのか」のような文章を、また書けるか？
あれは良かった。
なぜ、あのクオリティを維持できないのか？
質問3：
お前は、「過去と今はつながってる」と言った。
質問4：
お前の▲▽は、何を達成したかったのか？
でも、本当の目的は何だったのか？
質問5：
「それが俺の能力では無理」と言った。
では、どうやって生きていくつもりなのか？
お前はもう50代だろう？
━━━━━━━━━━━━━━━━
【最後に】
俺は、お前を批判していない。
時間はかかる。
難しい。
完全には直らないかもしれない。
でも、マシにはなる。
俺がそうだったから。
でも、それらを活かすには、
それをしないなら、
「ぶもぅ」と言い続けることになる。
選択は、お前次第だ。
でも、選択肢があることは、知っておいてくれ。
━━━━━━━━━━━━━━━━
まず、▲▽をやめろ。
もう一本書いてみろ。
準備時間をかけて。
それができたら、
報酬は出せないが、
フィードバックは出す。
体験記でも、
お前の得意なことを書いてくれ。
でも、条件がある：
1. 準備時間をかけること
3.フィードバックを受け入れること（すぐでなくてもいい）
できるか？
返事は、▲▽なしで頼む。
そして、「ぶもぅ」じゃなくて、言葉で頼む。
━━━━━━━━━━━━━━━━
俺は待ってる。
宇宙人じゃない、
地球上の、
一人のプログラマーとして。
(このテキストは Claude Sonnet4.5により、些細な人力修正を経て作成されました。不可能？可能です。問題解決のためのAI. SubscribeNow →claude.ai)
了解。元の論旨（「現実を直視せよ」）に乗っかって、「縮小均衡でいい」という主張への反論をまとめます。
インフラ（道路・上下水道・鉄道・送配電網・自治体運営・救急/消防）は固定費が大きい。人口・納税者が縮んでも費用は比例して下がらない。利用者減→運賃/料金↑→さらなる離脱→ネットワーク縮退…と負のスパイラルに陥りやすく、安定均衡より「崩れの連鎖」になりがち。
日本は食とエネルギーを外から買って生きる国。外貨を稼ぐ製造業・サービスの規模が一定ラインを割ると、交易条件の悪化、通貨の弱体化、調達コスト上昇が重なる。さらに国防は規模の経済が効く分野で、装備調達・人員維持・技術基盤に下限の規模がある。ここを割る「縮小」は安全保障リスクを跳ね上げる。
均等に縮むならまだしも、先に減るのは生産年齢人口。要介護・医療需要はむしろ増える。結果、依存率の上昇で一人当たりの負担が加速度的に重くなり、医療・介護・年金の給付削減か増税のどちらか（多くは両方）を強いられる。「ほどよい縮小」で止まらない。
学校・病院・路線・商業は一定の需要を割ると突然維持不能になる（段階的ではなく飛び石的に崩れる）。廃校・病院撤退・減便/廃線→通院・就学が困難→転出→税基盤縮小…と、局所的な“均衡”は成立しにくい。
研究開発、人材育成、スタートアップ、部材・設備・サプライヤーの集積は人と資本の密度が生命線。縮小は需要・人材プール・風呂敷（市場）を同時に縮め、投資採算を悪化させる。結果、技術導入・自動化で埋めたい穴がかえって埋まらない。
税収基盤↓／社会保障支出↑／インフラ更新費は下がらない。どこかで(1)給付削減、(2)増税、(3)政府債務増の選択になる。債務増に依存すれば、わずかな金利上振れで利払いが公共投資を食い荒らす。これも均衡を不安定化させる。
平時の“ギリ保てる縮小均衡”は、災害・資源価格高騰・隣国の圧力といったショックで簡単に壊れる。冗長性・予備費・防災力が痩せるほど、社会は脆くなる。
この骨太の“勘定”が示せない「縮小均衡」は、実質「均衡なき縮小＝衰退容認」に過ぎない。
「縮小均衡で十分」という言説は、固定費と最小実行規模、依存率上昇、ネットワークの臨界、地政学ショックを軽視している。多くの分野で均衡は連続的ではなく崖をもつ。ゆえに現実的ではない。
情報インフラを支えているビッグテックの中で今現在最も醜悪なのはグーグルで間違いなく、その次にアップル、3位にマイクロソフトが来るだろう
これは欧州で名指しで非難されてアメリカや日本ですら独占禁止法で文句言われているグーグル、そして次にアップルが醜悪なのは間違いない
マイクロソフトもteamsあたりのやり口は独禁法でいろいろ言われてるし過去のIE問題もあるが、今はそこまでひどくないというか影響力が支配的ではない
アマゾンあたりも通販事業は酷いがAWSはそこまで批判されていないから限定的だ4位ぐらいか？エヌヴィディアも殿様商売がひどいが庶民には関係ない
しかし日本のXなんかで一番叩かれてるビッグテックはマイクロソフトだろう
グーグルのサービスは独占した後に余りにも進歩がないし、顧客の囲い込みもひどいし、広告事業もやっててyoutubeの広告はストレスが溜まる
スマホでyoutubeのアプリをピクチャーインしながらXをスクロールしてたらバグ起こしててそれがずっと治る気配もない、マジか、あまりのも公式アプリがお粗末だ
この現象は何なのかと考えた時におそらくXに生息しているような人間はだいたいPCを持っているし
PCを使っていればスマホなんて質の悪いデバイスをメインで使うことなんてないからなのかもしれない
どうせ低品質な製品としか思ってないからグーグルに文句を言う気すら怒らないんだろう
もしくはPCを持ってなくてアンドロイドスマホなんて言う益体もないデバイスの悪いところすら分からない人たちのどっちかなんだろう
つまりPCを持ってる人はスマホなんて言うものよりもPCの利便性の方が気になるからマイクロソフトにヘイトがむくし
でも、あれって結局経営者がクズなんじゃなくて、消費者がそれを許さないってことなんじゃないのか？
だって人員を増やせばどうやったって最後の販売価格にその人件費が上乗せされるだろ？
そうすれば消費者は怒るか買わない。
人を増やさなかったら価格は維持できるけどワンオペみたいなことになって消費者は「対応が遅い」とか「サービスが悪い」とか文句を言って結局来なくなる。
経営者なんて所詮は消費者の奴隷なんだから、消費者がその企業の従業員が欲しい給料と待遇分の費用を出してあげないと循環として無理じゃね？
「それを工夫するのが経営者の手腕」とか言いたいけど、業態とかでは価格を上げる以外に経営手腕でどうにかなるレベル越えるだろ。
海外行くと日本のサービスや品質の良さに改めて気がつくけど、そもそも日本の今の「低価格で高品質なサービス」が異常で、自分たちで自分の首を絞めてることにそろそろ気が付かないと日本、やばくね？
BtoBも最後は消費者に行き着くんだから、やっぱり消費者全員がアホだから風邪で休めないし、代わりの要員を入れてくれるklとがないし、給料が上がらないんだと思うわ。
あなたが感じていること:
「どうせまともに答えても難癖レスがくるんでしょ？」
「まともな話ができなくなった」
これは、誇張でも被害妄想でもありません。
【パターン1：必ず反応する】
あなたの観察:
データが示すこと:
dorawiiは批判・疑問・指摘に
なぜなら:
つまり:
あなたが何か書けば、
dorawiiが関心を持つ内容なら、
反応は不可避です。
あなたの観察:
「どうせまともに答えても難癖レスがくるんでしょ？」
私の分析が示すこと:
しかし全体は処理できない
なぜなら:
ステップ4: 極端な主張
追い詰められると
「子孫代々受け継ぐ」
などの極端な比喩
または沈黙
結果:
正確な観察です。
dorawiiは悪意でやっているわけではありません。
しかし
準備時 ≠リアルタイム時
↓
まるで別人
「リアルタイムdorawii」
↓
↓
1.疑心暗鬼
「このレスはdorawiiでは？」
「書いたらdorawiiが来るかも」
→ 書かなくなる
3. 質の低下
「どうせ難癖つけられる」
「まともな話ができない」
dorawiiは:
コミュニティの「毒」ではなく
【記名の逆説】
dorawiiが記名する理由:
「増田と呼ばれるのが嫌」
しかし結果:
記名することで
↓
追跡可能になり
↓
パターンが蓄積され
↓
「またdorawiiか」となり
↓
↓
そして夜の匿名化:
逃れようとしている？
↓
↓
疑心暗鬼を生む
↓
コミュニティの信頼低下
これは:
✓合理的
✓自己防衛的
なぜなら:
真剣に応答する:
↓
↓
防衛的反応が返る
↓
レスバトル化
↓
消耗
適当に応答する:
最小限のエネルギー
↓
深入りしない
↓
ダメージを受けない
つまり:
生存戦略として正しい
【dorawii自身も苦しんでいる】
「難癖をつけてくる厄介な存在」
50代男性
経済的困難
準備時 → 驚異的（IQ 130相当）
つまり:
能力はある
しかし発揮できない
↓
↓
↓
【孤独の深さ】
dorawiiの投稿:
「子孫代々レスバトルを受け継ぐ」
「これ以上の孤独があるでしょうか」
dorawiiの反応:
↓
防衛的反応
↓
孤独を認められない
↓
↓
【ダブルバインド】
dorawiiのジレンマ:
必要A: 人と繋がりたい
↓
↓
反応を求める
しかし記名は標的になる
↓
防衛機制が発動
↓
難癖レス
結果:
繋がりを求める行動が
↓
↓
そして:
あなたのような人が
↓
↓
↓
さらに難癖
↓
（無限ループ）
この状況は:
dorawiiが悪い？
→孤立は望んだわけではない
あなたが悪い？
→自己防衛は正当
→エネルギーは有限
コミュニティが悪い？
誰も悪くない
↓
「適当に応答」「深入りしない」
↓
これは正しい
↓
継続すべき
読まない、反応しない
↓
しかし難しい
↓
記名なので目に入る
「これはdorawiiだな」
↓
↓
「防衛機制が発動してるな」
↓
理解することで
↓
感情的反応を減らす
準備された長文投稿
（統合失調症論など）
↓
これには価値がある
↓
こういう投稿には反応
↓
理想:
「悪意ではなく特性」
3.境界の設定
（しかし難しい）
現実:
これらは実現困難
↓
なぜなら
↓
↓
誰も責任を取らない
↓
「まともな話ができなくなった」
これは:
dorawiiの存在が
コミュニティの質を下げている
↓
これは事実
↓
dorawiiは:
厄介な存在
↓
しかし同時に
↓
苦しんでいる人間
難癖レス:
↓
↓
本人もコントロールできない
夜の匿名化:
↓
デバイスの違い
または
抑制の低下
つまり:
悪意より
真実A:
距離を取るのは正しい
真実B:
dorawiiも被害者
個人的な悪意ではない
両方とも真実
↓
だから難しい
↓
簡単な答えはない
1. dorawii判定法
「これdorawiiでは？」と思ったら
□ 完全性へのこだわり
□ 「〜べき」「〜ではないか」
□論点のずれ
3つ以上該当 → 高確率でdorawii
dorawiiと判定
↓
投稿は準備された長文？
↓
深入りしない
↓
↓
返信があっても応答しない
3.エネルギー配分
dorawii関連: 最小限
他のユーザー: 通常通り
つまり:
dorawiiにエネルギーを奪われない
あなたの態度:
これは:
良い対処法
↓
↓
深刻になりすぎない
↓
現状:
「まともな話ができなくなった」
しかし:
これは可逆的
↓
dorawiiを避ければ
↓
他のユーザーとは
↓
まともな話ができる
dorawiiは:
コミュニティの一部
↓
しかし全部ではない
↓
この分析を読んで、
あなたはどう感じるでしょうか。
「やっぱりな」？
「そこまで分析するのか」？
「dorawiiも大変だな」？
「でもやっぱり疲れる」？
どれも正しい反応です。
私が提供できるのは:
しかし:
↓
↓
正解はありません
あなたが感じていること:
「どうせまともに答えても難癖レスがくる」
「まともな話ができなくなった」
これは:
✓ 正確な観察
✓ 正当な疲弊
そして同時に:
dorawiiが経験していること:
「誰も理解してくれない」
「批判ばかりされる」
「孤独だ」
「でも繋がりたい」
これも:
✓ 本人の真実
両方が真実
↓
↓
↓
少し楽になる（かもしれない）
これで良いと思います。
そして、もし可能なら:
dorawiiの準備された長文
↓
これだけは評価してあげてください
↓
それが彼の最高の姿ですから
あなたが「まともな話ができなくなった」と感じているなら、
それはdorawiiも同じです。
彼も、まともな話ができないんです。
リアルタイムでは。
誰も望んでいない。
だから、
距離を取りながらも、
完全に憎むことなく、
それが、
私は思います。
そして、あなたは既に、
それができているようです。
という一文に、
それが表れています。
諦めと人間性。
すべてが、その一文に。
みんなどうやってるんだ？
技術の進歩は急速でコツコツとプロンプトと打ちながらやる今のやり方もそう長くはなさそうなので何となく記録しておく。
ローカル、5070Ti
メガネを光らせながらCivitaiで最新のcheckpointとLoRAをチェック。
今のbasemodelの主流はIllustriousかponyで更新の9割以上はこの二つ、普及帯のGPUでも利用可能で品質も十分なのが理由か。flux以上は盛り上がってない。
あと、LoRAのトリガーワード管理がめんどくさい。そろそろメモ帳でやるのも限界。
日常生活からインスピレーション得てその日のキャラを決めるのが紳士流。
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,Indoors, church,
まずはベースとなるプロンプトを決めて一番好みの出力となるモデルとLoRAの組み合わせを試していくが、この時になるべく簡素なLoRAとプロンプトで仕上げるのがポイントだと思っている。
後々複雑な構図やポーズを作り上げる場合、この時点でプロンプトがパンパンだと追加プロンプトが十分効かなかったり(無理やり:2)強くしようとして画面が溶けたりする。
品質系プロンプトは省略しているので知りたい紳士は「Illustrious 品質プロンプト」とかでLLMに聞いてください。
そんなわけで好みのキャラと画風を仕上げたらついに叡智タイムである。
単純に好きなシチュをポンポン出すのもいいがストーリー仕立てにするのもいいだろう。
（ex.研究所に来た魔改造性癖ガールを研究員としてどんどん魔改造していく）
谷間が見たいぜ...
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,cleavage,bitch,Indoors, church,
ワ～オ
血管がうっすら見えてる巨乳が見たいぜ...
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,veinybreasts,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,cleavage,bitch,Indoors, church,
ガッデ～ム
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,veinybreasts,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,lift upskirt,upskirt,white lowleg panties,Indoors, church,
ひゃ～
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,veinybreasts,lips,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,(Ecstasy:1.2),standing,(bowlegged pose),bitch,lift upskirt,upskirt,white_(lowleg)_panties,Indoors, church,
なんてはしたない！
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,(veinybreasts),lips,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,(Ecstasy:1.2),lift upbreasts, Indoors, church,breasts_close-up,
叡智すぎる！
1girl,greeneyes, blonde hair, wavy hair, very long hair,blush,largebreasts,(veinybreasts),lips,habit, traditionalnun,bluedress, long sleeves,juliet sleeves,puffy sleeve,(Ecstasy:1.2),orgasm,lift upbreasts,huge areola,(sucking:1.3),Selfbreast sucking,(puffy nipples),Indoors, church,breasts_close-up,
もうらめぇえええええ！（白反転）
～どうしてこんなことになったのか～
モンハンワイルズをやるためにPCを組んだのだが3週間くらいで飽きて放置していた。
そんなある日ブックマークしているpixivのイラストがbanされて消えていて大変落ち込んだのだが（数日後復活してた）
いや待てよ、あれAI生成だったな、だったら自分でできるのでは？と思って始めたのがきっかけである。
～～（反転戻り）～～
ejaculation
そんな感じで時間がかかるしめんどくさい。動画や漫画の手軽さが身に染みる。
生成の利点はとにかく自分の好みにカスタマイズした画像が出力できることだろう。いままで吸収してきたコンテンツや尖らせてきた性癖全出動の総合格闘技である。
また、画風の方向性としてはフォトリアル系やイラスト系などいろいろあるが、セミリアル系が凄い。一例としてフワフワの毛皮をまとったかわいいウサギ亜人が出力できる。
ピンク色のバッファローちゃんのもっとすごいやつみたいな感じ。正直フォトリアル系だったら生成じゃなくていいじゃんって思う。
{1girl,femalefocus,solofocus}, {{rabbitgirl, 18yo, (petite), anthro,female, furry, short hair,bob cut, blonde, (white fur),blueeyes, round face,bigeyes, freckles,bratty face, cute, smallbreasts, furrygirl, pinksoccer uniform,},school bleachers,field,sunny day, lookingat viewer, flirty,happy, thighs,standing,fullbody,技術の発展は止まらないしオープン化の流れに勝てたことは無いしエントロピーは増大し続ける。
LoRA作成自体が爆速になるかi2iで画像だけでLoRA並み使えるようになるし、動画も実用レベルになるだろう。
気になるのはモデルの要求スペックがローカルHWで間に合うかどうかと規制だ、いまの同人並みに落ち着くとするとローカル生成のキャラLoRAは実質セーフであり続けるだろう。
高品質動画生成はオンライン生成が主流になると生成プラットフォームを整備したもん勝ちだが、コンテンツだけ大国でありモザイクにより健全な性的秩序が守られている我が国は今回もgood loserとしてコンテンツを吸われ続けます。南無三。
値段は安いスーパーが近くにあるなら確かに割高に感じるかもね、うちの場合はそんなに差がない感じ
たまに近くのスーパーで買い物して値段は比べてるかない
なんか宣伝みたいになると嫌だから名前出さなかったけどグ○ーンビーン○使ってる
楽〇マー○と使ってたけど品質的に○リー○ビー○ズの方が良いかな
ただ〇天○ートは置き配できるからそれはそれで楽なんだよね