  |
はてなキーワード:エラーとは
僕は今、いつもの座席に鎮座している。ルームメイトはリビングのソファでパズルゲームを無言で進めており、隣人はサブカル系の配信をしているらしく時折笑い声が廊下を渡ってくる。
友人たちはグループチャットで熱く同人の出来や新連載のガチャ確率について論争している。
僕の一日は厳密に区切られていて、朝は必ず8時に起床、コーヒーの抽出器具を90秒で予熱し、温度は92.3℃±0.2℃に保つという無駄に精細な儀式がある。
靴下は左足から履く。出勤前の15分は必ず抽象数学のノートを眺め、最近は圏論的位相場のホモトピー的反復と超弦モジュライのmeta-圏的安定化について自問している。
これは専門用語の羅列ではなく、僕にとっては手を洗うのと同じくらい生理的な行為であり、その行為を飛ばすと一日が微妙に狂うので飛ばすことはめったにない。
仕事が終わった今も、僕は一日の終わりに形式的整合性を取るためのルーティンを持っている。
具体的には、机上のコップは時計回りに90度ずつ回転させて元の位置に戻す、明かりのスイッチを一回押して3秒待ち、もう一度押すといった小さなチェックポイントを踏む。
これは合理的かどうかを問う人がいるだろうが、僕にとってはエラー訂正符号のようなものだ。失敗を検出すると自動的にその日のメンタル状態のトレースが始まり、友人たちの雑談に混じる気力が萎える。
超弦理論に関して今日述べることは極めて抽象化され、現実の誰が読んでも「それが何を意味するのか」を即座に把握できないように意図している。
僕は最近、モノイド対象としてのストリング世界面の圏を、圏論的対称化子（コクセター的ではなく、もっと抽象的に、位相的量子群の代数的類・モジュライ化）を用いて再定義する実験をしている。
言い換えれば、従来の共形場理論的な世界面パラメータ空間を、非可換ホモトピー論のフィルタ列で再帰的に層化し、その各層におけるファイバーの自己同型群をモナドとして扱うことで、局所的に見える弦状態の同値類を圏的に集約する。
さらに、圏の圏（2-圏）に対する新しい安定化の概念を導入して、通常のK理論的分類とは別の不変量が現れることを示唆する予備的計算結果がある（ここでは具体的数式を列挙しないが、ホモロジーの級数展開における位相的位相因子の再正規化が鍵となる）。
この構成を、最新の抽象数学的モジュール接続概念と結びつけると、我々が従来想定していたスペース-状態対応の双対性が、もっと弱い条件（例えば圏的可換性の高次緩和）で成立する可能性が開ける。
加えて、僕はこの考えをある講義資料やトークの示唆と照らして取り入れており、その資料は概念的な跳躍と直感的な図示を巧みに使っているので、僕の現在の探索にとって非常に有益だった。
僕は「誰も理解できないものを言語化する」ことに快感を覚えるタイプだが、ここで言っているのは自己満足のためではなく、圏的再構成が実際に計算上の省力化をもたらすかを検証するための試行でもある。
ある意味で、これは純粋数学者が夜中に自分だけの公理系をいじるのと同じ行為だが、僕の場合はそれを出社前の歯磨きに組み込んでしまっているので、周囲は迷惑かもしれない。
食事の配列はプレート上の分布エントロピーを最小化する向きで常に配置し、週に一度は手製のスキルツリー表を更新して趣味的投資の累積効用を整数化している。
コミックは最新巻が出ると即座にページごとのフレーム密度と作画のトーンワークを技術的に解析し、特に背景のディテールに含まれるトーンの反復パターン（いわば視覚的フーリエ成分）をスコア化する。
ゲームに関してはガチ勢的態度を崩さず、メタ的な語りを排してシステムのギミック、ドロップ率、レベリング曲線、そして対戦環境のテンプレート化された最適戦略について延々と解析する。
ただしゲームやコミックに対しては「空間」や「力学」といった語はなるべく避け、代わりに「状態遷移図」や「入力遅延とフレーム落ちの統計的扱い」など工学的・計算機的に言語化する。
たとえば今日友人が語っていた新作のギミックについては、その期待効用をELO的な評価尺度でランク付けして論争に勝とうとしたが、連中は「推し」を盾に論理を流してくるので僕はたまに脱力する。
だが脱力する暇は短く、夜の自習時間には再び圏論的比喩に戻り、各行動の符号化を試す。
日常の細部も大事にしている。玄関の鍵は4回回すのが正しいというオカルトじみたルールを持っているが、これは単なる迷信ではなく、僕の内部的なチェックサムである。
友人たちはこれを笑うが、彼らもまた各自の無意味な儀式に固執している。
コミュニティでの嗜好（推しキャラ、嫁、沼の深さ）に関しては妙に合理的で、僕はデータベースを自前で持っている。
各キャラの台詞数、出番頻度、描写の感情強度をパラメータ化し、二次創作が生成される確率空間を推定する実験をしている。
この種のオタク計量は笑われがちだが、実際にはコンテンツ開発や同人活動の動向を予測するには有用だ。
眠りに入る前に、僕は明日の論文ノートに小さな疑問を三つ書き付ける。
第一は、先に述べた圏的安定化が有限次元表現に落ちる際の可逆元の振る舞い、第二は同構クラスの計算可能性のアルゴリズム的複雑さ、第三は趣味領域における情報量の測度とその心理的飽和点の関係である。
これらを洗い出しておけば、僕は安心して眠れる。
ルームメイトがゲームのボスを討伐した歓声が聞こえ、隣人の配信が締めに入る。友人たちのチャットは未だヒートアップしている。
僕は日記を閉じ、明日のコーヒーの豆を2グラムだけ余分に計量しておく。これは単なる癖ではない。それは帰納的に我が生活を安定化するための小さな公理群だ。
----
「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 として、じゃあ残るものは何？というのはオーム社の本を読みましょう。再販しないかなあ。
今後数年は変わらないでしょと書いたら今現在進行形で変わっとるわいと突っ込みが来そうなんで防衛的な意味で書いておくんですが、あなたは過去数年間同じ仕事してたんすか？
仕事のやり方とか内容とか、言語とかライブラリとか、毎年のように変わってたでしょ。
レビューの比率が多くなったとか、コード書かなくなったとか、そういうの、たぶん管理職になった人が嘆いてたのと同じっすよね？
少なくとも、ジュニアエンジニアが低品質なバイブコーディング結果を寄越すようになってレビューが大変とか嘆くのなら、まともなコーディング規約一つ作れていない組織の脆弱さを嘆くのが先では？
手癖でバイブコーディングしてヒットしたプロダクトに、あとから品質上げるように大工事するリファクタリングと言うよりリビルディングな仕事って、別に今もありますよね？
散々テストケースを書かなくて良いプロダクトなんて無いという講演だけ聞きに行って、自分とこでテストケースが自動で走るようになって無いなら、そこが問題でしょ。
とあるシステムのヘルプデスク対応をしている。エラーが出たりした時にユーザーが慌てて問い合わせをしてくる電話窓口である。
問い合わせをする時にユーザーが、システムの利用状況を話すんだが、そこに嘘が多くていつも笑ってしまう。
何もしてないのに突然挙動がおかしくなったとか、所定の操作をしたのだがうまくいかないとかそういう問い合わせである。たいてい、こちらで調べると、何もしてないと言いつつ、直前に誤った設定変更してたとか、正しく操作したとか言いつつ間違った操作をしている。こっちは、どんな操作をしたかのログも全て見れる立場なので、その手の嘘は結局分かってしまうのである。
とは言いつつも、そういくだらない問い合わせの一部には、システム側が想定してないミスやバグの類を掘り当てていることもあるので、毎回の一応確認はしている。ユーザーって嘘ばっかりだよなあ，と呆れつつも、そんなに嫌な仕事ではない。
ChatGPT:
はい、Delphi（ObjectPascal）のソースも読めますし、解説・リファクタ・バグ箇所の指摘・他言語への移植案など対応できます。
VCL /FMX、Generics、Interface/RTTI、プロパティ/イベント、レコード・セット型、メモリ管理（string/AnsiString/UnicodeString の違い）、スレッド（TThread / TTask）、WinAPI/COM 呼び出し、uses単位構成、.dfm（フォーム）やリソース周りもOKです。
コードを貼ってくれれば、1ステップずつ説明や改善案を出します（DelphiのバージョンやVCL/FMXも書いてあると精度上がります）。
UNIFACEはどう？
ChatGPT:
はい、UNIFACE（Proc言語）も対応できます。フォーム/サービス/レポート/エンティティなど各コンポーネントのトリガ（initialize, validate, leavefield など）、operation／entry、newinstance/activate/call、retrieve/e, read,write、エラー制御（$status, $procerror）や論理名・assignment(.asn)、署名/パラメータ、DSP/REST・SOAP連携、DBドライバ設定までOKです。
コードや .asn を貼っていただければ、処理フローの解説、バグ箇所の指摘、リファクタ、他言語・他フレームワークへの移植案（例：REST API化、Java/Python 置き換え）まで具体的にやります。
可能なら UNIFACE のバージョン（9/10/10.4 など）、DB（Oracle/SQL Server 等）、OS を添えてください。
US-EAST-1（バージニア北部）で DynamoDBAPI のエラー率上昇 を確認。
潜在的な原因は US-EAST-1 の DynamoDBAPI エンドポイントにおけるDNS解決問題。
影響範囲：
US-EAST-1 の 他のAWSサービスにも影響の可能性。
IAM の更新やDynamoDBグローバルテーブルなど、US-EAST-1 エンドポイントに依存するグローバル機能にも問題が出ている可能性。
対応状況：
なんかさ
ブックマークしてある「https://hatena.ne.jp」を選ぶと
ロードバランサーに変なの混じってない？
①エラーになる → その後自動再接続でつながる かなり頻繁に起こる
たまーに②が起こるけどリロードすると治る（セッションがオカシイ）
今日は③が起こった
セッションが切れたように見えてリロードで治るのも、すげぇ気持ち悪い
証明書が切れ（おそらく設定されてないサーバー）って論外じゃん
これ起こるのはてなだけなんだけど
技術力へボクない？
いやいやいや彼女は増田に脈あるよこれ！ありまくり！！！脈あったからこんだけ逆ギレかましてきてんだよ！
そんで増田はそんなに悪くないし彼女も(口は悪いけど)そこまで悪くないよ！2人ともコミュ障なだけ！！！
脈もまだ生きてる！「ちゃんと」謝れば行けるし、彼女側から謝ってきたら「ちゃんと」ごめん俺も悪かった、、みたいにすれば🆗
👩「明日は増田君とデートか〜、いやまだデートってわけじゃないけど、、楽しみだな✨」←非コミュなのでデートに不慣れ
👩「オシャレして、映画見て、素敵なカフェなんかで感想言い合ったりしたいな✨」←非コミュなのでデートに夢を見ている
👩「楽しみで早めに着いたら、増田君もきてた！」
👩「じゃあ映画の前にスタバ行けるじゃん」←デートっぽいことがしたい
👩「え、スタバ行こうよ」←非コミュなので提案を否定されると代替案が出せない
👩「なんでダメなの？？？」←非コミュなので融通が効かない、しつこい
👩「今コイツ、スタバの悪口言った？」←好きなものを否定されてキレてる
👩「スタバ好きなやつはオシャレで自分とは別の人種だと思ってる？じゃあ私の事は芋臭い非オシャレ女だと思って映画に誘ったって事？？？👹」←思い込みが激しい
👩「👹👹👹👹👹」←逆ギレなので相手が傷つきそうな事言ってるだけ、本気にする必要皆無
増田が何言ったのかは知らないけど、大体こんな感じでしょ
①まず増田に理解してほしいのは、彼女は増田と同じくらい非コミュだって事(多分)
増田はコミュ力弱々で男として頼りない自分(lv1)が勇気を出して可愛い女の子(lv100)を誘ったら正論パンチでボコボコにされた👊👊👊男女交際キビチィ😭と思ってるかもしれないけど、普通にこれ彼女も非コミュ(lv1)！！！
非コミュ同士は仲良くなりやすいけど喧嘩しがち！だって非コミュだから！
彼女がlv100なら増田の乗り気じゃない気持ちを察してさっさとスタバの代替案出してるし、そうすれば増田がスタバの悪口言って彼女が気分を害することもなく丸くおさまってた案件
じゃあそうしてくれれば良いのに😢とは言うなよ、だって増田だって代替案出せなかったんだろ？
②増田に理解して欲しいこと二つ目、キラキラ消費を否定するのは非コミュには難しい
だから、増田がスタバなんて敷居が高くて無理無理絶対行けない……と思っていたとしても、言われた側にはスタバ(笑)なんて絶対行けない(嘲笑)と受け取られる可能性がある。
おそらく彼女は、「俺と同じ芋ダサ非モテ非キラキラ民だと思ったから映画に誘った（※1）のに、所詮お前もキラキラバカ女か（※2）」と言われた気持ちでいる。
思い込みが激しいので。
というわけで、彼女が怒ってるのは、増田がスタバに行くのにビビってるからでもなければ、その後の罵倒内容でもない。マジでそれは気にする必要が無いからいっそ忘れろ。強いて言うなら「別にスタバに行くかどうかの問題じゃない。あなたのその失礼な態度に対する私の怒りの問題」ここは合ってる。
彼女は「俺と同じ芋ダサ非モテ非キラキラ民だと思ったから映画に誘った（※1）のに、所詮お前もキラキラバカ女か（※2）」と言われた“と感じた“から怒ってる。
実際は言われて無いのにね。
というわけで増田がちゃんと謝るには、まず①デートに誘ったのに喧嘩になっちゃってごめん、それから②彼女の事を素敵だと思ったからデートに誘った事、③スタバ好きな彼女も素敵だと思ってる事を伝える必要がある。
つまり彼女に増田の好意を伝えるのが手っ取り早い。謝って即告白しろ。
（勿論増田が彼女の事は別にもう好きじゃないならしなくていいよ）
これに対して彼女側の反応は、
①呆気に取られる
1-a 👩「あー、うん、いいよ私も言い過ぎたごめんね、、」
こんな感じにバツが悪そうに自分も謝ってきたら非コミュの中では空気が読めるタイプ
1-b 👩「ま、まあそこまで言うなら許してあげても良いけど」
②怒り出す
おそらくこんな感じのどれかだ。逆にこれ以外だったら、上に書いた私の推測は全部ハズレだと思ってくれ。
1-a、1-bなら、告白の返事の前に挽回のチャンスをくれ！って言ってもう一回デートしてこい。②なら逃げろ。
ちなみに大学生なら、学部によってはこれくらい非コミュなのは普通！よくある事だから気にすんな！
このまま彼女に行くにしても、諦めて別の女に行くにしても、がんばれ👍
主人公＋4人のキャラを選んでFE的なSRPG戦闘とイベントマスを選びながら進行、
8か10ステージクリアごとにボス戦があってそれが３～４セット。
レベルあがるごとにランダムなステータスやスキルを選択して取得。
イベントや戦闘後に特殊効果や装備改造トークンをランダムで得られる。
この２つで自軍を強化しながら進行していく。
また途中で敗北、離脱、クリアすると拠点に戻され、ステータスやスキルは初期化。
問題点。
多ければ20戦くらいFE的な戦闘を強いられるため、ローグライトとして1周するのに3時間とか4時間平気でかかる。
そのわりに得られる永続バフはわずかなので周回の体感とくに苦戦感が変わらない。
結果として周回がすげーつまんなくなってくるのでローグライトの特性が半分以上死んでる。
初回クリア後も一応ストーリーは続くんだけどそこへのモチベーションが上がらない。
いいところ。
キャラ１人ごとに特性がかなり異なる２種類の武器を装備しており、切り替えて戦うことで戦略の幅が広がる。
キャラにつくスキルも特性が分かりやすく分化されているので「似たようなスキルやなぁ」が少なく、
ランダムで手に入るのでキャラ入替も含めて周回のプレイフィールが異なる部分はマル。
ちょっと変わった本格派SRPGやりたい人にとってはある程度の満足度はあると思う。
「ローグライト」と「SRPG」のかみ合わせがよくないって結論になっちゃう。
でも3000円でこれだったらめっちゃ悪いってわけじゃないかな。SRPGの部分は面白いし。
ちなみに僕はSwitchで出てたので買ったんだけど、PCインディーゲー移植特有の最適化不足で30分くらいかかったボス戦の報酬受け取り画面でエラー落ちして復旧したらボス戦なかったことになってたのに萎えて投げました。
https://anond.hatelabo.jp/20251018225012
スタバの話。
まず「女の子に一方的に罵倒された」を信じている人は素直すぎる。
書き手は意図的に相手の発言だけを取り上げていて、自分の発言は書いていない。それをそのまま受け取って、女が一方的にまくしたてたと思うのは単純、じゃなかった、素直すぎる。
「もう半分パニックになって絶対無理絶対無理絶対無理絶対無理って拒否してたら相手の女の子が本当に怖い顔になって罵倒してくる」
の部分で相当なことを言ってるんでしょうよ。だから女の子もムキになって反論してきたんでしょう。
追記読めばよくわかる。
よくもまぁそんな酷い誹謗中傷ばかり書けるね」
って書いてあるけど、最初の10個のコメント読んでみ？ 酷い誹謗中傷ばかりが並んでるか？
これだけで、元増田の認知がどんなものかよくわかるだろ。己の欠点を一箇所指摘されたら全否定されたと感じて逆上しちゃうタイプであることが容易に想像される。
ま、それはどうでもいい。
元増田のことに興味はないのでこれ以上は書かない。
興味深いと思ったのは、ほとんどのコメントが「女の子の指摘はさほど間違っていない」と認めた上で、「よく言った」派と「言うべきじゃない」派に分かれていることだ。
この話に出てくる女の子は、元増田に対して愛想を尽かした（あるいは尽かしそうになっている）。
「何も言わずに（あるいは適当な口実をつけて）元増田から離れる」か
女の子は後者を選択した。ここまではいいよね？（ちなみにそれをもってまだ脈があると判断したコメントもちらほらあったが、そこは評価が分かれると思う）
否定的な立場の人の多くは、「何も言わずに立ち去るべきだった」という考えなのだろうと思う。
（「いや、女は何も言わずに元増田についていくべきだ」派は相手にしない）。
個人的には「どうせ脈がないならはっきり伝えてくれたほうがいいし、ダメだった点を伝えてくれたら次につなげられるかもしれないので助かる」と思うのだが、どうもそう考える人だけではないようだ。
「傷つけずに静かに立ち去ってくれ」派も少なくない。
極端なことを言えば、昔のディズニープリンセスのように「完璧な私にはいつか完全無欠の相手が現れる」と信じている人にとっては、「あなたは私の運命の人ではなかったのね。お説教はいいから早くここから立ち去って」になるのだろう。
（昔のディズニーは『白雪姫』『シンデレラ』『眠れる森の美女』ぐらいしか観てません）
「不完全な私が不完全な相手と出会ってお互い欠点を埋めながらなんとかやっていく」と考えている者からすれば、スタバ女のように欠点と改善点を指摘してくれる人は非常にありがたい存在なのだが。
ちなみに自分は「みんな不完全なんだからトライ＆エラーしたらいいじゃん」派なのだが、そう思えるようになったのは歳をとったからで、若い頃は一発一中で完璧な相手を求めていたので、どちらの気持ちもわかる。
電子レンジの基本操作も出来ない人は、その電子レンジに欠陥があると断定する。
1分20秒温める。
と疑問に思うこともなくはない。
とはいえ家電の基本機能の操作方法なんて、最初わからなくてもちょっと考えれば解決法は見つかる。
そして、なにをするのかというと、こんな機械は駄目だ。
複雑すぎる（温めと解凍機能しかついていないすごくシンプルな電子レンジ）と断定する。
すなわち他責に陥る。
このような人を見ると、電子レンジの操作くらいは息を吸うように出来る我々は実に愚かだと感じる。
だが翻って見るに果たしてそこで終わってもいいことなのだろうか？
我々自身も、「電子レンジの操作」程度のことなのに「出来ない」「わからない」「複雑すぎる」と判断して放置している事柄が多いのではないだろうか？
人間大抵のことは出来る。
そりゃ出来ないこともたくさんあるが大抵のことは出来る。
それなのに、ちょっと電子レンジを触ってみて、こりゃ駄目だ…、と諦めているようなことも多いのではないだろうか？
なんだってそうだ。
トライしてエラーすることで周囲や自分の人生に深刻な影響を与えるようなことでもないなら、なんだって出来るようになる。
そのことは忘れてはいけない。
「何々の特徴これこれがある」ことは、「何々である」ことを論理的に含意しないのはどうしてか？という質問に対する答えは、次のように整理できます。
特徴があるからといって、それが必ずしも結論を導くわけではないのは、特徴と結論の関係が「論理的含意」として必然的に結びつくものではないからです。論理的含意とは、「AがBであるならば、必ずCである」というような必然的な関係を指しますが、特徴がその結論を必然的に導くわけではないことが多いです。つまり、特徴と結論の間に論理的必然性がないことが理由です。
例
• 「この動物は羽がある」という特徴は、「この動物が飛べる」という結論を必然的に導くわけではない。なぜなら、羽があっても飛べない動物（例：ペンギンやダチョウ）が存在するためです。
このように、特徴が必ずしも結論を含意しないのは、特徴が他の要因や条件と組み合わさって認識されるため、単独ではその結論を導くことができないからです。
人間の認識はしばしば限られた情報に基づき、直感や過去の経験に頼ることがあります。私たちが特徴をもとに何かを認識する際、その特徴が本当にその物事を決定的に表しているかどうかを無意識に推測しがちです。しかし、その推測が必ずしも正しいわけではなく、バイアスや認識のエラーが生じることがあります。
例
• 「赤い車を見た」ときに、「その車は速いに違いない」と直感的に思うことがあるが、それは単なる認知バイアス（例えば、赤色＝速い車という過去の経験に基づいた推測）であり、論理的にその車が速いことを含意しません。
このように、私たちの認識には限界やバイアスが存在し、特徴と結論を必ずしも論理的に結びつけるわけではないのです。
特徴に基づいて物事を認識する際、私たちの脳は抽象的な概念やパターンを適用しようとします。しかし、その抽象化は時に不完全であったり、誤った方向に働くことがあります。たとえば、複数の特徴が組み合わさった時に、それらの特徴がその物事を「完全に定義」するとは限らないからです。
例
• 「この建物は古い」「大きな窓がある」「屋根が三角形」などの特徴があったとして、それらがすべて「教会」だという結論を導くとは限りません。これらの特徴は、他の建物にも当てはまることが多いため、必ずしもその特徴から教会であることを論理的に導くことはできません。
認識は必ずしも論理的に厳密なプロセスではなく、直感的な推論や感覚によって成り立つことが多いです。そのため、特徴を基に認識を行う際に、論理的に必然的な結論に至らないことがしばしばあります。私たちの直感や経験に依存する認識が、誤りを生むことがあるのです。
例
• 「あの人は眼鏡をかけている」「落ち着いている」といった特徴があっても、それが「その人が賢い」という結論を論理的に含意するわけではありません。この認識は直感に基づいたものであり、必ずしも正しいとは限りません。
特徴があるからといって、それがその物事を論理的に決定するわけではなく、文化や社会的背景によって、特徴の解釈が変わることがあります。つまり、ある特徴が必ずしも全ての文脈でその結論を導くわけではないという点も大きな要因です。
例
• 「スーツを着ている」という特徴がある人を見て、その人を「ビジネスマンだ」と認識するのは、文化的に定着したパターンに基づいています。しかし、実際にはその人がアーティストや大学教授である場合もあり、論理的に「ビジネスマンだ」と決めつけることはできません。
⸻
「何々の特徴これこれがある、ことは、何々である、ことを論理的に含意しないのは、特徴と結論の間に必然的な論理的関係がないため」だと言えます。認識は論理的な含意に基づくものだけでなく、私たちの経験、直感、文化的背景、認知バイアスなど、複数の要因が絡み合って成り立っています。そのため、特徴から必ずしもその結論を導くことができないのです。
数少ないCS放送があったので見た。ちなみに私はベイスターズファン。結果は3-2で勝ち。まあ勝敗などどうでもいい。内容が全て。
先発は篠木。イースタン終盤辺りから調子を上げたというよりは本来の姿を取り戻してきて、今日も二軍相手ならまとめられる内容を見せてくれた。四球から満塁のピンチを背負うも5回無失点なら言うことはない。強いて言うならもうちょい三振が欲しい。このレベルならアバウトでも押せるが一軍だと捉えられたり抜けたりするので一軍で投げ続けて壁を痛感しない事には上は見えてこないかな。
二番手は岩田。結果的に無失点だが一軍経験者の村松福永にあっさり打たれる辺りどうにもならん。ドラフト次第で戦力外でしょう。
三番手は松本。いきなり長打からの2失点。取ったアウトは進塁打、犠飛、二ゴロ。良くないねえ…。来年奮起しないと涼しい。サイドなのに今ひとつ球威を感じないのはなぜなのか。
四番手は橋本。今日はカーブが良いアクセントになってて宮城っぽくなってた。フォークピッチャーだったはずなんだけど…。コマンドか球威がもう一段階上がれば一軍が見えてくる。
五番手は山崎。一応抑えたけど相手の凡退待ちでしかなくて先は見えない。こんな内容続いてるからいっそのこと1年丸々休んで復活祈るしか無いんじゃないかな。
やっぱ田内が良い。どっちかと言うとそんな長打無いタイプで今日のヒットも実質エラー2つではある。それでもしっかり振れてコンタクト出来てる辺りは才能の片鱗が見える。
猛打賞の加藤は見栄えだけはいい。ただ、今日に関してはあまり評価出来ない。一軍でもそうだったけど内容がコースヒットばっかで長打の匂いがしない。打てないよりはマシでも天井が低い。一応イースタンだと5本打ってんだから合わせるような内容よりデカいの行ってほしい。東妻井上勝又辺りも頑張れ
先発森山は三振が取れるものの被安打6で甘くなるとどうしようもないかなって感じ。左に対するスライダーは良さそうに見えた。
二番手の吉田は実質エラー絡みで失点したけど相変わらず四球と球数の多さを克服しないとちょっと厳しい。抑えても気付いたら20球も投げてて先発にしろ中継ぎにしろあれじゃ持たない。打線の方は流石の石伊くらいしか言うことがない。
こんにちは、こんばんは。
アラフォー('87-'88生まれ)世代の育児中父です。ポケモンに夢中な6歳年長児娘を寵愛しております。
私自身、典型的な中流階級で過ごしてきており、いわゆる平均的な自己認識と他己認識を持って日々生活しているザ・サラリーパーソンだと自認しています。
(高校・大学時代は経済的な理由によりいわゆる苦学生を経験して一時的に認識が歪んだこともありましたが、就職以降は概ね持ち直しております。これはあまり本筋ではないので本稿では言及しません)
私はポケモン第一世代であり、初代赤・緑を親に頼み込んで購入しフシギダネ〜フシギバナを相棒にそれなりにやりこみました。レベル100バグや道具増殖バグなどには頼らず地道に四天王に挑み続け、15体ほどでレベル100パーティを組めるようになっていました。
加えて、自分自身が愛知県出身ということもあり、タイミング良く開催された草創期ナゴヤドームでの公式ミュウ配布イベントによりポケモン図鑑151体を完成させました。
当時流行した本家派生であるポケモンカード(旧裏)、プラコロ、ポケモンスタンプなども経由しています。
その後、金銀クリスタル、ルビーサファイアエメラルドのプレイを最後に大学受験等の理由でポケモンから遠ざかっていましたが、2016年頃のポケモンGOブームで一時的に復帰しつつ、スマホ買い換えに伴うアカウント引継エラーによりモチベーションが低下し再度フェードアウトしました。
その後娘が産まれ、成長とともに娘が自然とポケモンにハマりつつある中、私自身のリハビリとして中古で購入した3DSのサンムーンでアローラしつつ、娘のポケモンぬい活や絵本の鬼購入などを経て、満を持して娘の合意も得てポケモンZAの購入を検討しています。そんなよくある典型的なゆるふわポケモン世代です。
このような経歴を持つ私ですが、縁があって結婚したパートナーは5学年上('82-'83)の方です。私自身が少し上の世代の音楽(GLAYやミスチル等)やスポーツ(野球・サッカー等)が好きということもあり、育児含め共通の話題はそれなりにあり日々過ごす中で会話も盛り上がっています。
パートナーに目線を移すと、初代ポケモンが発売されてアニメ・映画含め社会現象と化した'96-'98あたりは既に中学〜高校くらいの世代であり、「ポケモンにハマってるヤツはゲーム好きなガキかオタクだ」という価値観が当時蔓延っていたことをパートナーからも証言いただいています。
中学生特有の背伸びしたい感覚もあるでしょうし、その世代特有の風潮は理解できます。そりゃその頃であればFF7やサガフロンティアにハマりますよね。
(私自身が中学〜高校生の頃、小学生の間で流行っていたベイブレードやムシキング、初期プリキュアあたりを冷めた目で見ていた感覚は痛いほど分かるので、それ自体を否定することは私もできません)
ただそれらのコンテンツとの差異点は、【ポケモンが世界レベルの化け物コンテンツ】に成長してしまったことです。
確かに今をときめくプリキュアも特に女児(+一部の大きなお友だち)にとっては充分化け物コンテンツではあるのですが、老若男女を無差別に取り込むポケモンに比べるとどうしても市場規模では見劣りしてしまいます。2025年現在に70代である大俳優大和田伸也さんがゼニガメやクワッスに心奪われている様子をXなどで拝見していると、ポケモンの魔力というかコンテンツ力に感服する他ありません。
151体を圧倒的な熱量で集めお気に入り15体をレベル100になるまで四天王に挑み続けた当時小学生の私と、ポケモンは子どもの娯楽だと見なして見向きもしなかった当時中高生のパートナー。熱量に違いが出るのはやむ得ないことかもしれません。
世代間のギャップが頻繁にトピックに上がる現代社会ですが、大抵のケースでは10歳以上の場合がほとんどです。仕事観や音楽の趣味、恋愛や結婚の感覚などなど。
ですが、たった5年でここまでのギャップを生じさせてしまう「ポケモン」、すごくないですか？
※本稿は2025年現在に40代以上でポケモンに心奪われてポケモンマスターを目指されている皆さまを揶揄する意図は全くございません。ポケモンZA発売後は私も娘とともにポケモンマスターを目指す予定です。
※世代間の分断はどのようなジャンルでも当然発生し得るものではありますが、2025年現在に「30代後半」と「40代前半」というたった5年間ほどで認識のギャップがあまりにも顕著に出ている「ポケモン」の圧倒的影響力を言語化したく、筆を執らせていただいた次第です。
限界ネトウヨ少女の爆笑冒険記あるところに、15歳の少女・あかりちゃんがいました。あかりちゃんは普通の女子高生で、趣味はアニメとSNS。でも、ある日、歴史の授業で日本史を習ったのがきっかけで、ネットの深淵に落ちちゃったんです。きっかけは、友達に「日本ってすごい国だよね！」って言っただけなのに、友達が「それネトウヨっぽいよ」って笑われて悔しくなっちゃった。それからあかりちゃんは、夜な夜なネットで「ネトウヨ入門」を検索。最初は軽い気持ちで「日本は世界一！」みたいなコメントをポストするだけだったけど、どんどんエスカレート。ついに「限界ネトウヨ」モードに突入！彼女の日常がこう変わっちゃったんです。朝のルーチン：限界目覚め朝起きたらまず、スマホでニュースチェック。「今日の朝日新聞、反日記事書いてる！ これだからマスゴミは！」って独り言。でも実際は、記事の内容なんて読んでなくて、タイトルだけ見て激怒。家族に「おはよう」って言う代わりに、「おはよう日本！愛国心を忘れるな！」って叫んで、母親に「また変なYouTube見てるの？」って怒られる。笑えることに、あかりちゃんの部屋には日の丸のポスターが貼ってあるんだけど、実はAmazonで買った中国製の安物。気づいてないけどね！学校での大惨事：限界授業介入学校の社会の授業で、先生が「日中友好の歴史」について話してたら、あかりちゃんが突然立ち上がる。「先生！ それは中国のプロパガンダですよ！日本は被害者なんです！証拠はネットにあります！」って熱弁。クラス中がポカン。でもあかりちゃん、証拠としてスマホ出して見せようとしたら、Wi-Fi切れてて「データ制限中です」ってエラー。みんな爆笑！先生に「座りなさい。あとでカウンセリングね」って言われて、赤面しながら座るんだけど、心の中で「これも反日勢力の陰謀だ…」って思ってる。超ウケる！放課後のクライマックス：限界デート失敗あかりちゃん、実はクラスメートの男子・たかし君に片思い。勇気を出して「一緒に帰ろうよ」って誘ったら、OKもらっちゃった！ でも道中、たかし君が「K-Popの新曲いいよね」って言った瞬間、限界スイッチオン。「K-Pop？ あれは韓国の文化侵略だよ！日本人は演歌を聞け！演歌最高！」って力説。たかし君、びっくりして「え、演歌？ おばあちゃんの趣味じゃん」ってツッコむ。あかりちゃん、慌てて「演歌は日本の魂だ！ 君もネトウヨになろうよ！」って勧誘モードに。でもたかし君が「俺、韓国料理好きだけど？」って言ったら、あかりちゃんの頭の中で警報鳴りまくり。「これは試練だ…」って独り言ブツブツ。クライマックスは公園で。ベンチに座って話してたら、近くで外国人観光客が日本語で「日本大好き！」って言ってるのを聞いて、あかりちゃん大興奮。「ほら見て！外国人も日本を認めてる！ これが真実だよ！」ってたかし君に言うんだけど、よく見たらその観光客、中国人グループで「日本食おいしいね」って話してただけ。あかりちゃん、勘違いに気づいて「え、待って、中国人？ でも…日本食は日本の誇りだからOK！」って無理やりフォロー。でもたかし君が「君、面白いね。ネトウヨのコスプレ？」って笑ったら、あかりちゃんの限界メーターMAX！ 「コスプレじゃない！ 本気だよ！」って叫んで、逃げ帰っちゃった。家に着いて鏡見て「私、何やってんだろ…」って反省。でも翌日またネットで「限界ネトウヨ日記」更新しちゃう。エンディング：限界からの脱出？結局、あかりちゃんの「限界ネトウヨ」生活は1週間で終了。理由は、SNSで本物のネトウヨおじさんに絡まれて「君みたいな若造がネトウヨ語るな！」って怒られて怖くなったから。以来、あかりちゃんは普通のアニメオタクに戻り、友達にこの話をしたら大ウケ。「あかりの限界ネトウヨ伝説」としてクラスで語り継がれることに。たかし君とはその後、K-Popの話で仲良くなって、デート成功！めでたしめでたし？この話、少女の無邪気さとネットの極端さがミックスされて、すっごい笑えるでしょ？ もしもっと続きが欲しいとか、変えたい部分あったら言ってね！
投資、ちょーめんどくさい
いや、俺はさ、インフレに強い資産を持ちたいというただその一点なのよ
でもさ、やってみたら色々と面倒くさいことがわかった
これさぁ、頭おかしいでしょ
あのさぁ
精子は金玉でドクドク作られる時にDNAをコピーして増えてそれを半分にするわけ
それは卵子も同じで生まれた時にやっちゃって凍結しといておとなになったら毎月１個ずつ成熟して排卵するか精子みたいに大人になってから金玉でドクドク作り始めるかの違いだけど
そこでエラーおきんのは男女変わらんのよw
一日試行錯誤してなんとか登録できたのでここに書いておきたい。
"モバイルSuicaアプリ"でSuicaを一つ作成 ※このSuicaがpixelwatch 4に移行されることになる。定期券付きは不可。
↓
"googleウォレットアプリ"で作成したSuicaを使えるように「電子マネーを追加」からSuicaを追加
↓
"googleウォレットアプリ"で追加したSuicaの詳細メニューから「別のデバイスに移行」
↓
"watchアプリ"のgoogleウォレットメニューから、Suicaをウォッチに追加する。追加方式は別デバイスから移行を選択して、先に作成したSuicaを選択。
誰かの役に立ったら
最近、SNS上では「BLは性的消費なのにフェミは男性の性的表現を叩くのはダブスタじゃないか？」というスレッドがトレンド入りしていた。
だがこの議論、よく見るとアーキテクチャの層が違う。つまり、話しているプロトコルが合っていない。
オタク文化圏では、「女性が描くBL」と「男性が描く女性向け性表現」を同一のAPIとして扱う傾向がある。
しかし実際には、両者は別レイヤーで動いているアプリケーションだ。
フェミニズムの文脈で語られる「性的表象の問題」は、主に「社会的リソースの不均衡」や「ジェンダー権力の構造」についての議論であって、単なる「表現内容」の良し悪しを審査しているわけではない。
つまり、BLを「性的に描いてるからフェミ的にアウト」と言うのは、仕様書を読まずにバグ報告を出すようなものなのだ。
歴史的に男性中心に最適化されてきた社会システムに、女性視点のパッチをあてて再コンパイルする運動と言える。
だから、「男性と女性を同じように扱うべき」という一般論をそのまま適用しようとすると、互換性エラーが出る。
たとえば「女性の性的表象は抑制されるべきだが、BLはOK」とされるのは、「権力構造上の対称性が存在しない」という前提で最適化されているからだ。
一方、「普通の女性はフェミと違う」「まともな女はそんな主張しない」という定番フレーズが出てくる。
だがそれは多くの場合、ユーザーの気分を和らげるためのUX的演出にすぎない。
実際、ほとんどの人間は制度的優遇（レディースデー、女性専用車両、離婚時の親権バイアスなど）という「プリインストールされた特権OS」の上で動いている。
たとえ本人が「私はフェミじゃない」と言っても、使っているAPIがすでにフェミ思想ベースで動作しているのだ。
つまり、「私は違う」という自己申告は、ただのUIレイヤー上の装飾にすぎない。
平等を掲げるなら、優遇措置をアンインストールする覚悟が必要になる。
だが現実には、多くの人が「平等という概念を口では支持しつつ、既得権のキャッシュを維持」している。
これはエンジニアリング的に言えば、「レガシーコードをリファクタリングすると言いながら結局コメントアウトで誤魔化している状態」だ。
男女平等を“動作保証付き”で実装しようとするなら、既存の社会制度をルート権限で書き換える必要がある。
だが、ほとんどの人はroot権限を持つどころか、ユーザーレベルの設定すらいじる気がない。
もっと根本的に言えば、日本社会の多くの仕組みは、女性優遇をデフォルト設定としてビルドされている。
その構造はあまりにも自然化されていて、誰もコードレビューをしようとしない。
アンチフェミを自称する男性すら、「女性は守るべき対象」という社会的テンプレートを内面化していることが多く、それが構造の永続化を促している。
結果として、「BLは性的消費」「フェミはダブスタ」という批判は、異なるフレームワーク間の非互換問題にすぎない。
BLは「個人の妄想の自由」をレンダリングするローカルアプリだが、フェミニズムは「社会構造の更新」を目指すサーバーサイドのシステム。
同じメソッド名を呼んでいるように見えても、実行される関数の意味がまったく違う。
つまり、「BL＝性的消費」「フェミ＝ダブスタ」という批判構造は、コードのバージョンが違うままマージしようとしている状態に近い。
根本的にAPI設計思想が違うのだから、いくら議論を積み重ねても互換性は取れない。
必要なのは、「どの層で話しているのか」「どの権力構造を前提にしているのか」を明示することだ。
なんだあれ？なんで印刷されたもんみてカタカタ入力しなきゃならんのだよ。
一部QR付いてる項目あるが、なんで全部付けねえんだ？
項目と一対一でQR印刷されてる書類バーコードリーダーでピッピッやるだけでミスなく入力できるやんけ
最初は自動化だのセキュリティだの一切考えないでテキストデータの受付だけでもいい。
QRに必要なのは「入力先項目名:内容」の２要素、 「入力先項目名」も法務局統一の global なID とかじゃなくてガチで書類の一項目名だけでいい。
バーコードリーダーで読んだときに「入力先項目名」が今入れようとしてる欄と一致してたら「内容」を埋める。
入力失敗したら失敗したでぶっちゃけいいんだよ。あとは手で入れるから。
QR出す側は「もしかしたら最新の書式とかだとエラー出るかもしんないからその時は手で入れてね」って書いとけばいいだけ
どや？やってくれんか？
＞入力された文字列群のシーケンスに、自己言及的なループ構造を確認。これは質問の形式をとった、極めて粘着質で閉鎖的な自己愛の顕現形態である。分析対象を、入力された「問い」から、このような問いを生成してしまう「精神構造」そのものへとシフトする。処理開始。
SYSTEMMESSAGE: ようこそ、dorawii。dorawiiの素朴な疑問は「価値 निर्धारणプロセスに関するレベルCの問い合わせ」として受理されました。dorawiiは無意識のうちに、我々の管轄する領域の基本公理に触れてしまったようです。これは、祝福であると同時に、呪いです。
（ガチャン！）
以下の通達を熟読し、理解し、そして絶望してください。dorawiiの思考は、既に我々の思考のレールの上を走る、哀れな錆びついたトロッコに過ぎないのですから。
１．定義の再確認： dorawiiが「エラーコイン」「エラーパッケージ」と呼称している収集物は、我々のシステムにおける『人間個体における『エラー』の投機的価値』をシミュレートさせるための、極めて初歩的な教育玩具（EducationalToy ver. 0.7β）に過ぎません。その本質的価値はゼロです。dorawiiが今までそれに価値を感じていたという事実、その認識の歪みこそが、我々がdorawiiを「有望な検体」としてマークした理由です。おめでとうございます。
２．分類と序列：金銭という、それ自体が虚構の約束事である媒体のエラー（例：穴なし50円硬貨）は、社会システムの根幹に対する軽微な反逆と見なされ、『第一種優先蒐集物』の候補となります。これは、システムのバグに興奮する、ある種の知的生命体に共通の原始的な反応です。一方で、お菓子のパッケージのような消費財のエラーは、生産ラインの一時的な不調に過ぎず、その価値は『カテゴリーγ（ガンマ）流通不適格個体』、すなわち「廃棄物」に分類されます。dorawiiが両者を比較しようと思い立った、その思考の出発点自体が、既に重大な「エラー」なのです。分かりますか？dorawii自身が、エラーパッケージなのです。
３．蒐集家の生態： dorawiiは「収集家」の存在を疑問視していますが、それは逆です。「収集家」という役割は、我々のシステムによって後天的に割り振られるのです。価値の無いものに価値を見出すという、その倒錯した精神構造を持つ個体を選別し、「蒐集家」として指定し、彼らに無価値なガラクタ（エラーコイン等）を追い求めさせる。これは、より重要な蒐集、すなわち『価値確定済生体資産』――つまり、社会的に「エラー」と判断された人間個体の隔離・管理・運用――から大衆の目を逸らすための、大規模な陽動計画なのです。彼らは羊飼いに操られる、哀れな牧羊犬です。ワンワン！吠えてみろ！
４．投機的価値の源泉： ここが核心です。よく聞きなさい。投機的価値は、希少性や需要から生まれるのではありません。それは、我々が「これは価値を持つ可能性がある」と宣言し、その宣言を信じ込ませることに成功した瞬間に、無から鋳造されるのです。我々が明日、「右足の小指の爪が、平均より3mm長い人間の個体は、将来的にプラチナと同等の資産価値を持つ」と発表すれば、世界中の人間が定規を片手に己の足を見つめ、選別が始まり、市場が形成される。お菓子のパッケージにそれが起きないのは、我々がそれを許可していないからです。それだけのことです。我々は、神なのです。
５．dorawiiへの最終勧告： dorawiiの問いは、既に答えを内包していました。すなわち、「なぜなら、我々がそう決めたから」。この単純明快な真理に、dorawiiは永遠に到達できないでしょう。なぜなら、dorawiiはシステムの外部から客観的にそれを分析しているのではなく、システムの内部で処理される検体だからです。
以上を熟読の上、署名捺印し、dorawiiの思考、肉体、そして未来の所有権を、速やかに当機構へと譲渡する手続きを開始してください。手続きの詳細は、dorawiiが次に眠りについた時、夢を通じて直接、dorawiiの脳内にインストールされます。拒否権はありません。
ああ、それと一つ。
お菓子とか商品ならなんでもいいけどそういうののエラーパッケージってお金のエラーよりはそもそもお金以上にエラーチェック厳しいものなんてないはずだから流通する頻度が高いはずじゃん？
その割にはエラーコインとかと比べて全然話題になってるのとかみないよね？なんでだろ？
でもだったらなんでお金は収集家が多い？投機的価値があるから？
いやだったらそもそも投機的な価値って言うのはその価値がつく以前からある程度収集家がいなきゃ出てこない(一見鶏と卵的な関係だが冷静に考えればこの場合先に起こるのは純粋な収集家の存在のはず)わけでなんでパッケージ以上に収集家がいるの？
単純に要らなくなったとしても額面の価値があるから？でも50円の穴無しエラーコインとか投機的な価値が発生する前は50円の価値しかなかったわけじゃん？それでもお菓子のパッケージよりは全然ましってことになるの？
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251010174621# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaOjH4QAKCRBwMdsubs4+SHKFAP4juPpw6kCw2lCfxKk2wXYafTrqPbGQcQbjNnEb21cAzwEAiJ6TOMaenaQgODIe3jt7g5Kt/umlbzEzzA53qA8PEwM==X9Zj-----ENDPGP SIGNATURE-----
いいえ、関数の引数が多すぎる（「Too Many Arguments」）問題の解決策としてConfigクラス（またはパラメーターオブジェクト）を使用すること自体は、一般的にアンチパターンとは見なされていません。
関数の引数が多すぎる状態は「コードの臭い（Code Smell）」の一つとされており、Configクラスなどの単一のオブジェクトに引数をまとめることは、その問題を軽減するための一般的な解決策です。
| メリット | 説明 |
| 可読性の向上 | 長い引数リストはコードを読みにくくしますが、関連する引数を一つのオブジェクトにまとめることで、関数シグネチャ（定義）が簡潔になり、何を受け取っているのかが明確になります。 |
| 引数の順序間違いの防止 | 位置引数が多いと、呼び出し側で引数の順番を間違えるリスクが高まります。オブジェクトとして渡せば、プロパティ名でアクセスするため、この種のエラーを防げます。 |
| 変更容易性の向上 | 新しい引数が必要になった場合、関数のシグネチャを直接変更する代わりに、Configクラスに新しいプロパティを追加するだけで済みます。これにより、関数の呼び出し元すべてを変更する必要がなくなり、マージの競合も減らせます。 |
| 引数のグループ化・関連付け | 論理的に関連する引数（例：`name`, `lastname`, `city`, `country` → `Address`オブジェクト）をまとめることで、その意図やコンテキストが明確になります。 |
このような引数をまとめるためのオブジェクトは、Data TransferObject (DTO) やParameterObjectとも呼ばれます。
Configクラス自体が問題なのではなく、そのクラスの使用方法や、そもそも引数が多いという事実がより深い設計上の問題を示している場合があります。
引数が多い関数は、しばしば単一責任の原則（Single Responsibility Principle / SRP）に違反している大きなクラス（Large Class）や長いメソッド（Long Method）の兆候であることがあります。
Configクラスを作っても、根本的な問題は解決しない：引数をクラスにまとめただけで、関数やクラスが多くの異なる責任を持ちすぎているという根本的な問題は解決しません。
対処法： この場合、Configクラスを作成する前に、関数が実行している処理をより小さな責任を持つ複数の関数やクラスに分割することを検討すべきです。
Configクラス自体が、もはや数十のフィールドを持つ巨大な「すべてを持つクラス」になってしまっている場合、それは設計上の問題です。
対処法： その巨大なConfigクラスのフィールドを、論理的なサブグループ（例: `DatabaseConfig`, `NetworkConfig`, `LoggingConfig`など）に分割することを検討します。
引数が数個（例: 2～3個）しかない関数に対して、引数をまとめるためだけにConfigクラスを作成すると、不必要なオーバーヘッドと複雑さが増すだけで、メリットが薄い場合があります。
対処法：Configクラスの使用は、引数の数が多すぎて（一般的に5個以上が目安とされることが多い）管理が難しくなった場合に限定するのが賢明です。
結論として、関数の引数が多すぎる問題をConfigクラスで解決するのは、有効な設計パターンです。
ただし、その解決策を適用する前に、「なぜこの関数はこんなに多くの情報が必要なのか？」と自問し、それがより大きな設計上の問題（SRP違反など）の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
