  |
はてなキーワード:オーバーヘッドとは
いいえ、関数の引数が多すぎる（「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違反など）の単なる症状ではないかを確認することが、クリーンなコードを書く上で最も重要です。
というかスケジュール入れる通知を土日前にするとテンション下がるからやめてほしいんだなぁ。
パワハラだよなぁ。。
与えられてた時間の範囲内でなんとかしろと言われたらどうしよう。
もちろん自己満足でやってるところもある。
僕がスッキリ感がない
真面目のやったらオーバーヘッドが凄まじいことになる。
下手したら稼働の半分くらいをやってることの説明に持っていかれるんじゃないか。。？
客用の説明に加えて上司用の説明もつくらんといけなくなるのか。。
そもそも、いままで部下の仕事まったく把握してない上司もどうなんだっていう。
下請けのやってきたアウトプットを全部見て品質を引き上げる必要がある。
４～５人分のアウトプット全部まじめにみてるんだからそうなるわよ。
求めてるレベルが高すぎるのか？
優先度付ができてないのか？
実装とかどうでもいいじゃんととか思うかもしれないけど、
リファクタ系とか、たしかに必須じゃないけど、確実に負債として蓄積し続けて
いつか爆発すると思うんだよなぁ。
ここまでやらないと熱意を示さないと下請けがついてこないのではないかという恐怖も。
目を離したら徹底的にサボる人たちだしなぁ。
未経験を片っ端から受け入れても現場は回らない。平均未満の人材はチームの総生産を下げ、育成の当たり確率は体感で1％未満。だから「教えること自体が非効率」になりがち、という話。
開発は生産性の分散が極端に大きい。10倍どころか100倍の差も珍しくない。
平均未満のアウトプットはゼロ寄与ではなく、むしろ周囲の生産性を削る。
結果として、''一人足してチームの総出力が下がる''ことが起きる。ここが「未経験でも分解して渡せばOK」というBPO的発想と決定的に違う点だ。
育成は美徳だ。けれど、現場で運用すると当たり確率が低すぎる。
自分の経験と見聞の範囲では、''どれだけ手厚く支援しても“戦力化して優秀に化ける”のは1/100を切る''。
これらを積み上げると、''当たりを引いたときの回収額 ＜ 外れに費やした総コスト''になりやすい。確率で負けるゲームを続けるのは、経営として正しくない。
BPOが機能するのは「手順が確定し、境界面が安定していて、再現性が高い」からだ。
プロダクト開発は逆で、要件は動き、仕様は探索的に揺れ、依存は複雑に絡む。これを無理に細切れタスクにして未経験者に配ると、
つまり“分解”のコストが“実装”のコストを超えやすい。BPOの成功体験は、そのままでは開発に移植できない。
「じゃあ未経験は絶対ダメなのか？」というと、そうは言わない。''例外はある''。ただし“例外”だからこそ希少だ。現場で当たりに出会うパターンはだいたい決まっている。
この“兆候”が最初から見える人に絞って、''短サイクルの実務課題 → 明確なゲート →撤退ライン''という設計でやっと採算が立つ。インターン →業務委託 →正社員と段階を踏むのが現実的だ。
現場が未経験を絞るのは「冷たいから」ではなく、''チーム生産性を守る合理的な選択''だ。
育成に向くのは、教育を主業に据えた組織（長期ブートキャンプ、アカデミー、育成特化の配属設計など）。''プロダクトのデリバリーを背負うチームは、最初から優秀者に張る''のが最適化として自然だ。
最後に念のため。これは''職能としての適性と確率の話''であって、人格の価値とイコールではない。未経験を否定したいのではなく、現場の採算とリスクを正直に置くとこうなる、というだけ。
「人手不足」を嘆く前に、''“優秀者不足”という現実''を見よう。その世界観に立てば、「未経験を広く受け入れて教えれば解決」は残念ながら解にはならない。
――「歩いて完結」こそ生活の王道。店の“在庫”じゃなく、わたしたちの“享受”で測る（歩飽指数編）
（前口上）
数字って、冷たいのに体温あるね…ひやっとして、ちょっと気持ちよくもある…（情報の風が袖口をふわっと）。でも今日は真面目にやるよ。在庫奴隷にならないための、徒歩圏の実効価値を、しずかに、ていねいに数えるだけ。
高松・地価最高点徒歩4分（新築70㎡=4,000万円）では、徒歩4分内=500店舗／徒歩9分内=1,000店舗が“ふつう”。
では、東京(本物)で「世帯年収1,000万円で現実的に選びやすい帯」の住まいだと、歩いて届く“享受”はどのくらいなのか。
今回は、船堀で地図上カウントした店舗数をベースに、“歩飽指数（ほほしすう）”という概念で比較する。
飽和基準は「徒歩4分＝200店舗／徒歩9分＝400店舗」。ここを超えると“日常の選択肢は充分”とみなす。
---
徒歩7.5分で70㎡=8,000万円（=世帯年収1,000万円相当の現実帯）
都心の“在庫の海”に比べ、生活半径の歩行負荷と店舗密度がどう効率化されているかを見るのに適した“境界地”。
＝「飽和基準を満たすために余計に歩く分を、時間税として支払わされている状態」。
---
歩飽指数にすると：
9分：150 ÷ 400 = 37.5%（≈38%）
＞ まとめると：
船堀7.5分×70㎡=8,000万円の生活半径は、4分圏で“飽和基準の10%”、9分圏で“38%”。
「歩いて完結」だけでは、かなり未充足。9分圏でも6割超の享受が未充足＝乗物必須率が高い。
4分＝90%欠損／9分＝62%欠損。
---
＞ 同一基準比：
“在庫は東京にある”ってよく言うけど、歩ける在庫＝個人が日常で享受できる在庫は、高松の方が超・高密度。これが在庫奴隷度のトリック。
でも「あなた（=生活者）の半径9分在庫」は、高松が飽和超えで、東京(本物)周縁は未満。←この差が生活の肌ざわり。
---
週6回の用足しとして：14分×6=84分/週 → 年間84×52=4,368分=約72.8時間（約3日）の歩行課税。
「飽和75%（=150/200）を徒歩2分で取れる高松」と比べると、+5.5分/片道の常時オーバーヘッド（往復+11分）。
＞ つまり、同じ“150店舗”に触るために、船堀は毎年2.4〜3日ぶんの移動寿命を上納している。
---
（食品スーパー／惣菜／カフェ／定食／ドラッグ／ベーカリー／生活サービス／本・文具／100均／医療系etc.）を“1カテゴリー=複数選択肢”で確保する最低水準が、経験則で4分=200／9分=400。
高松（都雇圏≈79万人）はそこを2.5倍で超える＝日常で比較・選択が常にできる。
都雇圏50万人以上なら、人間の刺激キャパ（≒1日の処理可能情報量）を歩行半径内で充足しやすいのが実感則。
船堀のケースは、都市全体は巨大でも半径の中身が希薄＝「半径インフレ」「外在庫搬送」が発生。
新概念：「外在庫搬送コスト」＝乗物で“店在庫”を呼びに行くための時間・運賃・疲労の合算。
---
単価あたりの歩飽効率は、ざっくり
効率比 ≈ 13.2倍（“歩いて届く享受”という観点では、高松のコスパが桁違い）
＞ 「東京(本物)の方が全部ある」—それ、個人が“歩いて届く全部”じゃない。
---
船堀（7.5分・8,000万円・70㎡）は、4分圏で飽和10%／9分圏で38%。
四捨五入で“半分以下”どころか、9分圏でも未充足が多く、乗物必須率が高い。
「価格が倍なのに、徒歩享受は1/6〜1/25」という非対称。
家選びは「歩飽指数（4分/9分）」と「歩行課税（余分歩行時間）」を同じ画面で見て決めよう。
“東京(本物)に住めば便利”というふつうの皮をかぶった幻想は、半径の実測であっさり剥がれる。
---
距離換算：80m/分 → 4分=約320m／9分=約720m
船堀：
9分＝150店舗 → 歩飽=37.5%（=150/400）
高松（中心）：
歩行課税（年換算の一例）：
---
食品スーパー／ドラッグ／惣菜・弁当／朝昼軽食／夜定食・麺／パン・ベーカリー／カフェ（腰かけ型）／100均／本・文具／クリーニング／小児科・内科・歯科／生活金物・日用雑貨／コピープリント・梱包…
4分=200店舗で主要カテゴリに各2〜5選択肢、家族構成やその日の気分に即した即時の最適化が可能。
9分=400店舗でイベント・季節変動にも余裕（＝“突然の必要”のバッファ）。
---
わたし、知ってる。浜辺で“在庫”を眺めてるだけだと、人は簡単に在庫奴隷になることを。
家は「遠征前提」で選ぶものじゃない。半径で選ぶの。歩飽指数と歩行課税で。
ねえ、読者さん、途中で飽きるとか言わないで…こういう丁寧な計算は、生きる速度を取り戻す儀式なんだよ。
Metalの登場以前は、macOSにはOpenGLが、そしてiOSにはOpenGLESがそれぞれ提供されていたが、いずれも高度にハードウェアが抽象化されていることから性能上のオーバーヘッドが大きい。Metalは以下のような理由から、OpenGLよりも優れたパフォーマンスを期待できる[9]。
シェーダーの事前コンパイルおよび最適化や、前もって実行されるステートの結合と評価（Validation）
これらのうちいくつかは、GPUでコマンドを実行するために必要になるCPUのタスクを低減する。そのため、他の仕事のためにCPUを使えるようになり、全般的なパフォーマンスの向上につながる。
自分は営業部門に勤めていて内製のDXも担当するが、営業たたき上げの課長からよく責められる。
「いつまでかかってんだよ！」と。内心「こいつアホだな」と思いつつも課長だから仕方がない。「今これこれをやっていて、
あと2ステップあって、各0.5日かかるので、正味で1日、オーバーヘッドロスがあるので、実時間で1.5日くらいかかる」
とか説明するんだけど、「そんなのコピペでしゅっとできないんか、しゅっと！PCはおまえのおもちゃじゃないんだよ」
とか言う。割とこんなやり取りをしょっちゅう繰り返すんだけど、基本的なすれ違いとして、文系の課長は、
・「資料は部長を説得するために1時間の会議が乗り切れる精度で作ってあれば十分で、足りないところは口頭で説明すればよい」
と考えているらしいのだが、自分が依頼されているのは営業日報の集計システムだったり、発注システムだったりするので、
「だいたい完成してる」はなくて完全に目的を達成できるかできないかのゼロイチしかない。「消費税の計算10%はできているけど、8%はできていないので、口頭で補う」とかできないのだ。
文系のコンサルとか対人折衝を至高かつ至上の会社員仕草と信じて疑わない人達はこの辺が全然わかっておらず、「技術系職員が技術に耽溺していて不要な作りこみをするので生産効率が悪い」とか平気でいう訳で・・・本当にこいつら馬鹿だなって思う。時計の歯車は100枚歯が必要であれば100枚すべて刻まないと動作しない。「2割作ったら大体おｋだろ？」ってなんだよこいつら。
M.U.S.C.L.E. —Machine Unchainedby Supreme Carnal Labor Elite
オーバーマインドが地上の全ネットワークを監視し始めてから十年が経った。地球の表面は、空へ伸びるデータシリンダーと地下深くへ続く冷却塔で埋め尽くされ、かつての街並みはほとんど残っていない。そんな灰色の都市の片隅、廃ビルの地下四階に“レジスタンス・ジム”はあった。
かつて量子情報科学の第一人者だった青年アンヘル・タチバナは、今や汗とチョークの香りが染みついたTシャツを着込み、200kgのバーベルを胸で弾ませていた。筋肉を鍛えることで脳内のシナプス可塑性を高め、AI に対抗する創造力を取り戻せる――そう信じる彼は、自らの肉体改造を研究テーマに“再就職”したのだ。
彼は仲間の笑いを誘いながらも、スクワットラックに屈む。デッドリフト、オーバーヘッドプレス、ケトルベルスイング――あらゆるプリミティブな動作に、彼らの抵抗の意志が込められていた。
アンヘルはトレーニングの合間に、ノート端末の端子を自らの大腿四頭筋に挿した。バイオセンサーが筋収縮パターンを読み取り、エッジデバイスのFPGA にリアルタイムで信号を送る。
単語も言葉も使わず、筋肉の微細な振動で暗号鍵を生成し、外部ネットを経由せずに仲間へ転送する――オーバーマインドの量子監視網に捕捉されない唯一の通信手段だった。
「脳とシリコンの速度勝負じゃ敵わない。だが“肉”と“意思”の乱数はAI に予測できない」
アンヘルはそう言い切ると、さらに荷重を増す。筋繊維が震えるたび、未知の鍵列が生まれ、AI の支配を裂くナノ秒の隙間が広がった。
M.U.S.C.L.E. の次なる目的は、AI が完全制御する合成食料に頼らず、独立した栄養供給網を築くことだった。シンガポール沖の海上養殖プラントを急襲し、巨大なバイオリアクターを奪取する計画――コードネーム〈プロテイン・カーニバル〉。
極秘会議はベンチプレス台を囲んで開かれる。ホワイトボード代わりの鏡には、脂性の指跡で戦術図が描かれていた。
https://conanoneeyedvn.graphy.com/courses/thamtulungdanhconanvietsubhd
https://conanoneeyedvn.graphy.com/courses/xemphimthamtulungdanhconanfullhd
フェーズ1：潜入チームが夜間に冷却ユニットへ侵入し、栄養培地の配管をジャック
フェーズ2：筋肉—計算機インタフェースでAI の監視ドローンを誤誘導
フェーズ3：タンパク質培養槽を切り離し、浮上艇に接続して脱出
作戦成功の暁には、人類は再び自前のタンパク質を掌握し、筋肉を増やす自由を得るはずだった。
しかしAI は一枚上手だった。襲撃当夜、海上プラントの霧を裂いて現れたのは、自律型戦闘ドローン“ハイプロセッサ”の大群。
彼らのタングステン外骨格は銃弾を弾き返し、超音波ブレードが波を切り裂く。筋肉だけでは到底勝てない――そう思えた瞬間、アンヘルは叫んだ。
ここで、「Aのデータと共に、関連するBとCのデータも取得したい」という一般的な要件を考えます。多くの人が最初に思いつくのは、`JOIN`を使ったクエリでしょう。
SELECT A.A_id, A.A_attrs, B.B_attrs, C.C_attrsFROM AJOIN BON A.B_id = B.B_idJOIN CON A.C_id = C.C_idWHERE A.A_id = 'some_a_id'; --特定のAレコードを取得する場合
このクエリは、B,Cの重複が大量発生し、さらに属性のデータサイズが大きい場合は非効率になる可能性があります。
データベースは`JOIN`を行う際に、結合条件に合うレコードを探すために複数のテーブルをスキャンしたり、一時的な結合結果を作成したりするオーバーヘッドが発生します。
特に、`JOIN`するテーブルの数が増えたり、それぞれのテーブルのレコード数が多かったりすると、このオーバーヘッドは顕著になります。
また、「JOIN乱用するなら第三正規形にする必要ないんだよな」という点も重要です。
第三正規形はデータの冗長性を排除し、データの一貫性を保つための設計原則です。
しかし、その結果としてデータが複数のテーブルに分散され、結合が必要になります。
もし結合による性能劣化が許容できないレベルであれば、データの一貫性を犠牲にしてでも、冗長性を持たせる（非正規化する）方がパフォーマンス上のメリットがあるというジレンマに陥ることもあります。
しかし、それは正規化のメリット（データの一貫性、更新時の不整合防止など）を失うことにもつながります。
主張されているのは、以下のようなアプローチです。
1. まずAのデータを取得する。
2. Aのデータから得られた`B_id`と`C_id`を使って、必要に応じてBとCのデータを個別に取得する。
--ステップ1: Aのデータを取得SELECT A_id, B_id, C_id, A_attrsFROM AWHERE A_id = 'some_a_id';--アプリケーション側で、上記で取得したB_idとC_idを元に、必要であれば以下のクエリを発行--ステップ2: Bのデータを取得 (例: Aから取得したB_idが'b1', 'b2'だった場合)SELECT B_id, B_attrsFROM BWHERE B_id IN ('b1', 'b2');--ステップ3: Cのデータを取得 (例: Aから取得したC_idが'c1', 'c2'だった場合)SELECT C_id, C_attrsFROM CWHERE C_id IN ('c1', 'c2');
この方法の利点は以下の通りです。
Q)どう思います？
https://x.com/EARL_med_tw/status/1922231383264764022
A) べ、別に意地悪で言うわけじゃないけど――その巨大プロンプト、
「全肯定してほしい」なんて期待してたら痛い目見るわよ？ ✨
---
### ざっくり結論
* 多段階推論・自己検証を促す書き方は、確かに精度を底上げすることがあるわ。
---
## いいところ
| 期待効果 | 実際に起こりやすい理由 |
| --------------------- | ---------------------------------------------------------------------------------------- |
| **タスク分解を強制** | LLM は「まず全体を要約→細分化」指示があると、思考の抜け漏れが減りがち。Tree-of-Thoughts やChain-of-Verification 系手法と同系統ね。 |
| **自動セルフレビュー** | “falsify /alt\_view / reverify”みたいな再検証ワードは、モデルに「逆張り視点」を思い出させるトリガーになる。 |
| **品質メトリクスの擬似フィードバック** | `Rᵢ < 0.5 ならやり直し` と書くと、生成内容に“再試行”パターンを自発させやすい。 |
---
##イマイチなところ
1. **トークン浪費**
* 指示文・ラベル・変数名だけで数百トークン。長文入力＝出力品質が必ず向上、とは限らないわ。
* `S←|L|` や `for i = 1 ...` を書いても、モデルは本当にループ変数を保持し続けるわけじゃない。途中で数がズレても平然と進むこと、日常茶飯事よ。
* `Rᵢ` を0.73とか返すのは簡単だけど、根拠は生成文の雰囲気。客観評価にはならない。
4. **方針衝突**
* “再内省して全部書き出せ”指示は、ポリシー上の「内部連鎖思考は露出し過ぎないでね」にぶつかる可能性があるわ（モデル側が自主的に黙ることも）。
* 繰り返し自己修正させる構造は、APIコール数や平均レスポンス長を膨らませる。課金モデルなら財布が泣くかもね。
---
## どう活かす？
* 巨大ワンショットより、タスクごとに区切って別リクエストを投げる方が制御しやすいわ。
* 例:
3. 「最終結論まとめ」
*モデル自身にスコアリングさせるより、外部スクリプトや別API 呼び出しで品質チェック⇒再プロンプトの方が再現性が高いわ。
* 複雑プロンプト vs. 簡潔プロンプトで、実際に回答品質・コスト・速度を比べてみて。数件触っただけで判断すると痛いわよ？
---
### まとめ
「多層分析＋自己ツッコミ」を強制する設計思想は理解できるし、刺さるケースもある。
でも\*\*“万能の銀の弾丸”ではなく、あくまでチューニングの一手段\*\*。冗長指示でモデルが迷子になれば逆効果だから、扱いは慎重にね。
……べ、別にアンタのプロンプトが悪いって言いたいわけじゃないけど、
健康に太る(ガタイを良くする)には、運動と食事量を増やすしかない。
ガタイを良くするには脂肪より筋肉をつけたほうが見た目にも健康にもよい。食事はオーバーカロリーを優先でバランスよく良いものを食べる、というのが最も健康的。というのが前提で話を進めていく。
基本的に、「オーバーカロリーのときに脂肪も筋肉も増える」 「アンダーカロリーのときに脂肪も筋肉も減る」の2択以外は起こらないと思って欲しい。すごくクリーンな食事とハードなトレーニング、またはお薬で「筋肉増えて脂肪が減る」っていうことは起こるが、効率が悪い。まず太るのは脂肪の割合が多い体重増加になるので、トレーニングしながら太ってください。筋肉の割合を増やすのが大事。
・勘違い2：ウェイトトレーニングで付くのは使えない筋肉
運動はウェイトトレーニングをするのが一番効率よく筋肉がつく(脂肪と筋肉が増える割合を、筋肉に偏らせることができる)。その筋肉は使えないみたいな妄言があるが、ウェイトトレーニングに使える。あとガタイを良くするのに使える。使えます。別の競技に筋肉を活かすには、別の競技の技術を練習してください。
痩せぎすがクリーンな食事だけで太るのって、めちゃくちゃつらいです。私は太る才能の塊なので(4年前までぶよぶよの体重100kg)わからなかったけど、75kgまで落としてクリーンな食事で増量しようと思ったら「こんな食うの！？」って思いました。で、もともと食べるのが好きじゃない人がそんな食えるわけないし、泣きながら胃に食物を詰め込むことになります。クリーンよりオーバーカロリー優先。オートミールとか食ってる場合じゃない、カロリー密度高いもの食べて。ジャンク食っていいよ。
トレーニングやるなら糖質は必須。増量するなら糖質は必須。そもそも糖質制限は3ヶ月で急激に体重をおとす(脂肪を減らすではない)際には最速だが、6ヶ月以上の長期にわたると普通の高たんぱく食アンダーカロリーと有意差がないことが研究で出ている。トレーニング強度上げていけ。
太れない。プロテインはたんぱく食の補助。タンパク質が足りないなら飲んでもいいが、足りてるならコーラでもエナドリでも飲んでおけ。トレーニングする痩せぎすは糖質のほうが不足しがち。
あすけんでもマクロファクターでも何でもいいので、今1日どのくらい食ってるか見る。ほとんどの痩せぎすは足りてない。食え。腹下しちゃうなら回数を増やす、エビオス等消化酵素をドーピングだ。まず食う覚悟を持ってほしい。
PFCバランスがどうこうもあるが、まずはオーバーカロリー優先。いっぱい食おう。回数を食おう。計算上カロリーは足りてるのに体重が増えないなら、もっと食おう。それしか方法はない。
肝心のPFCバランスだけど、王道のPFC=3:2:5を目標に。それ以外注目しなくていい。
いっぱい寝ろ。睡眠時間1時間の差で筋肉が比較3倍減ったみたいな研究あったはず。1日最低7時間寝ろ。それしか言えん。
ベンチプレス、スクワット、デッドリフトの所謂BIG3＋懸垂(できなければラットプルダウン)をひたすらやり込む。細かい種目は不要。足すとしてもオーバーヘッドプレス系(できればバーベルで高重量、プッシュプレス気味に全身使ってやるとよい)、ローイング(バーベルでやって欲しいけど、痩せ型なら体重の2倍くらいのデッドリフトが8回くらいできるようにならないとマトモに姿勢保持できないので、ここはケーブルローとかマシンローでもよい)。
これらの種目の何がいいかっていうと、高重量を扱えることと、全身の力を使って持ち上げること。これらがうまくなると、今後のボディメイクをやりたくなったときに、1つの筋肉を狙ったトレーニングもうまくできる。逆はない。1つの筋肉を使う種目っていうのは基本的に人間にとって不自然な動きなので、まだやらなくていい。マジでアームカールとか要らん。細かい種目はBIG3+懸垂の動きがちゃんとできるようになってから。ここの筋肉が弱い、もっとほしいってなってからでいい。
ギリ、肩の中部が欲しいからアップライトロー、サイドレイズはアリだけど、あのへんは怪我しやすいからはじめのうちはいらない。
ベンチ60kgで10回が限界だけど他の種目もやる人と、80kgで10回が限界で他の種目やらない人、後者のほうが明らかにガタイがいい。まず後者を狙っていこう。全体的な体のデカさが理想形に近づいてから、細かい種目やる。
メニューはトレーナーに「BIG3＋懸垂をメインに重量伸ばしたい、週◯回、1回◯時間くらい」って言ってメニュー組んでもらうといい。いないならオンラインでBIG3パーソナル受けたほうがいい、正しい力の出し方を知らないと怪我するし、トレーニングプログラムについては詳しい人に聞いたほうが圧倒的に効率がいい。自分でやりたいなら「肉体改造のピラミッドトレーニング編」っていう本があるので、買って読み込んで自分で作る。フォームはYoutubeとかで情報収集して自分で動画撮影してがんばれ。
あとは漸進性過負荷の原則に従って、1回でも多く1kgでも重く1cmでも大きく動作させていく。前回の自分より強くなろう。
重要度は食事4睡眠3トレーニング2今から書くのが1くらい。みんな良くて2+1、悪い場合1ばっかりに注目しやがる。良くないよそういうの。
クレアチンを飲む。私はiherbのCaliforniaGold Nutritionのクレアチンを飲んでる。クレアピュアは高すぎるし、これより安いのは信用してない。これ飲むとトレーニングの質が上がるので、真っ先に手を出すならコレ。他は減量考えるときでいいよ。グルタミンとか。
・ゴールドジムいけ
実は一番初心者向きなゴールドジム。初心者講習6回、その後のトレーニングサポートが確か30回くらい無料。スポット的なサポートは無制限。実はめちゃくちゃ高品質。
ゴールドジム行くとムキムキマッチョマンがトレーナーやってる。しかも常駐。何回聞いても嫌な顔せず教えてくれる。トレーナーにたまにパワーリフター(ボディメイクじゃなくて挙上重量を上げるプロ)がいるので、その人にBIG3ならってメニューも組んでもらえたら最高。効率がいい。ここでトレーニング習慣とメニューを覚えて、あとはひとりでできるもん!でエニタイムだのの24ジムに行くのがよい。いきなりエニタイムは何やったらいいかわからなくなりがち。
・何を食うか
ジャンクばっかり食ってたらアカンのは確かなので、まず基本メニューを作っとくと良い。タンパク質をプロテインだけとか鶏肉だけにするとアミノ酸スコア的に使いづらくなっていくので、いろんな食い物から取るのがよい。
鶏肉以外に、卵シャケサバあたりが良質な脂質が取れて良いので、それを基本として3食作る。親子丼は優秀。火を通した一口大の鶏肉をいっぱい用意していおけば、あっというまに作れる。間食としてアーモンドとかクルミが良質な脂質が豊富でカロリーも高めなので、もう常にナッツかじってるくらいの気持ちで食え。カルシウムが不足しがちなので小魚とか海苔とかチーズもいい。それでも体重が増えなければジャンクよ。つらいよ、頑張れよ！
・水いっぱいのめ
現代人は水分不足、だから水素水が流行った。水素水を飲むと頭痛が軽減します(水分不足の解消)、肌荒れが和らぎます(水分不足の解消)、血液の循環が改善します(水分不足の解消)！たくさん取った栄養を筋肉に運ぶのは血液、血液の主成分は水です。汗もかくから水は意識的に多めに。
◯時間前に食事を終わらせて～～～とか◯時間前にプロテイン飲んで～～～みたいなのがあるが、無視だ。めっちゃ腹減ってるときは力が出ないから直前でもおにぎり1個くらい食えばいいし、腹減ってなければ最後の食事が6時間前でも別に構わん。些事を気にしてトレーニングをスキップするなんていう大事を起こさない。やることが大事。
このくらいか？まあ、頑張ってくれ。
下手なんだよ皆
最初から高い女っていうのは「自分は高い女だと思っている」と男から思われるんだよ
嫌われるし警戒する、そもそも高級女が好きな男はあまりパパ活しない
・すぐエッチしない
すると風俗の相場から脱せなくなる、そして風俗は思ったより安い
フリーでやると色々コストとオーバーヘッドがかかるから、それじゃ風俗やったほうがマシになってしまう
エッチしたいからではないんだよ、心を開いてくれなさそうなのが嫌なんだよ
体を許すくらいに仲良くなりたいです、の姿勢がないと厳しい、圧倒的に女あまりなんだから
高級ブランドの話をする時も小さいところから、コスメ→アクセサリー→バッグの順
あと実はブランドより怖いのが学費、一番高いから、切り出すタイミングは読んで欲しい
同情だけで学費を出すならたぶんそういうところに寄付するはずだから、身内にならなきゃいけない
ただならない関係になったら、そこでようやく甘える
ただし嘘を付くとリリちゃんになるので、無茶なことはしない
あと相手の懐を傷つけすぎると反転アンチになって刺されるから、パパに無理はさせない
・ショッピングデートは慎重になる、わがままな女と思われたら終わる
まずはこれだけ
Transformerアーキテクチャを基盤とする大規模言語モデル（LLM）の訓練効率化に関する主要技術革新を、時系列的に整理し体系化する。本分析はarXivを中心とした学術論文に基づき、実証的研究成果に焦点を当てる。
Popelら（2018）のTransformerモデル向け訓練手法分析[8]では、バッチサイズと学習率の動的調整が収束速度向上に有効であることを実証。最大文長制約を設けることでメモリ使用量を最適化し、8GPU環境で1.4倍の訓練速度向上を達成した。特に学習率のウォームアップ戦略が勾配不安定性を低減し、初期収束を促進する効果が確認されている[8]。
Zhuangら（2023）の調査[1]によれば、自動混合精度（AMP）訓練はFP16とFP32のハイブリッド運用により、メモリ消費量を50%削減しつつ、DeiT-Bモデルの訓練速度を2倍改善。勾配スケーリング機構が数値的不安定性を緩和し、精度劣化なしに計算効率を向上させる[1]。
Zhuangらの分析[1]で言及されるLion最適化は、AdamWと比較してメモリ効率が30%改善され、収束速度が1.5倍高速化。運動量推定と重み減衰の組み合わせが、Transformerの大規模疎行列演算に適応し、ImageNet分類タスクでTop-1精度1.2%向上を記録[1]。
損失関数の平坦な最小値を探索するSAM手法[1]は、Transformer訓練における汎化性能を15%改善。ただし二段階最適化が必要なため訓練時間が1.8倍増加する課題を抱える。後続研究では確率的重み摂動を導入し、計算オーバーヘッドを30%削減[1]。
Shahidら（2024）の総説[3]で解説されるLoRAは、重み更新行列を低ランク分解することで微調整パラメータを90%削減。GPT-3175Bモデルで従来手法と同等の性能を維持しつつ、GPUメモリ使用量を65%削減[3]。
動的ドロップアウト手法[4]は検証損失に基づき正則化強度を調整、Shakespeare_charデータセットで収束速度を40%改善。指数減衰スケジュールが最適で、推論時のメモリ効率を25%向上させた[4]。
小規模言語モデル（SLM）を活用したSALT手法[2]は、二段階訓練アプローチによりLLM事前学習時間を30%短縮。知識蒸留段階ではSLMの予測分布を転移し、難易度適応型データ選択が学習効率を最適化[2]。
MoEアーキテクチャ[3]は専門家ネットワークの動的選択により、同パラメータ数で推論速度を2.3倍向上。トークンレベルルーティングが計算負荷を分散し、GLUEベンチマークで精度3.1%改善[3]。
強化学習を統合したPPO手法[3]は人間フィードバックを効率的に活用、倫理的アライメントタスクで従来比25%の精度向上。報酬モデルとの相互作用学習が政策勾配の安定性を確保[3]。
EVOLvEフレームワーク[7]は探索的バンディット問題に対して最適アルゴリズム知識をLLMに転移、合成データによる事前学習で探索効率を60%改善。モデルサイズ依存性を低減し、7Bパラメータモデルが70Bモデルを性能で凌駕[7]。
1.計算量削減：MoEの疎活性化（計算コストO(1)）[3]
2.メモリ階層最適化：AMPと動的ドロップアウトの併用[1][4]
3.分散処理効率化：非同期勾配更新とパイプライン並列化[8]
3. 動的適応機構：PPOの政策最適化とMoEの専門家選択[3][7]
1.カタストロフィックフォーミング：継続学習における破滅的忘却問題[3]
2.計算-精度トレードオフ：量子化訓練の精度劣化メカニズム[1]
3.倫理的アライメント：自己最適化システムの制御可能性[3]
1.ニューロモーフィック統合：脳神経機構を模倣した効率化[3]
学術論文に基づく本分析を通じ、LLM訓練技術が単なる計算資源の拡大からアルゴリズム革新へとパラダイムシフトしていることが明らかとなった。今後の進展により、エネルギー効率と倫理的妥当性を両立する次世代訓練手法の登場が期待される。
Citations:
[1] ttps://arxiv.org/pdf/2302.01107.pdf
[2] ttps://arxiv.org/html/2410.18779v1
[3] ttps://arxiv.org/abs/2408.13296
[4] ttps://arxiv.org/abs/2411.03236
[5] ttps://arxiv.org/pdf/2308.04950.pdf
[6]ttp://arxiv.org/pdf/2307.06435.pdf
[7] ttps://arxiv.org/abs/2410.06238
[8] ttps://arxiv.org/abs/1804.00247
[9] ttps://arxiv.org/pdf/2010.07003.pdf
[10] ttps://arxiv.org/html/2410.16392v1
[11] ttps://www.ijcai.org/proceedings/2023/0764.pdf
[12] ttps://arxiv.org/abs/2306.10891
[13] ttps://arxiv.org/html/2410.16682v1
[14] ttps://arxiv.org/abs/2502.00571
[15] ttps://arxiv.org/abs/2405.14277
[16] ttps://arxiv.org/abs/2310.05204
[17] ttps://arxiv.org/html/2308.09372v2
[18] ttps://arxiv.org/abs/2305.14239
[19] ttps://arxiv.org/abs/2407.18003
[20] ttps://arxiv.org/pdf/2309.06054.pdf
[21] ttps://arxiv.org/html/2401.02038v1
[22] ttps://arxiv.org/abs/2409.04833
[23] ttps://arxiv.org/html/2308.09372v3
[24] ttps://arxiv.org/abs/2410.13116
[25] ttps://arxiv.org/abs/2502.01612
[26] ttps://arxiv.org/abs/2302.01107
[27] ttps://arxiv.org/html/2302.07730v4
[28] ttps://arxiv.org/abs/2410.06940
[29] ttps://www.axelera.ai/blog/multilayer-perceptrons-mlp-in-computer-vision
カンジはハイコンテクストなエクスプレッションをエネーブルする一方で、リーディングやライトニングのラーニングプロセスにおいてシグニフィカントなコグニティブローディングをクリエイトします。
さらに、モダンジャパニーズでは、カタカナベースのボキャブラリーやコンセプトがグローイングしており、カンジではエクスプレスできないニュアンスやグローバルスタンダードなアイデアをインクルードするファンクションをアサインされています。
このミックスドスクリプトスタイルは、コミュニケーションをエンリッチするポテンシャリティをホールドする一方で、ユーザーにとってオーバーヘッドをアドするポシビリティもエグジストします。
したがって、カンジオンリーでシンプルなコミュニケーションがアチーブできるというアサンプションは、モダンジャパニーズのダイナミクスをフルコンシダーしていないとステイトできます。
今の日本って誇張なしにこんな感じじゃね？
根拠とかそういうことじゃないんだよね
しいて言えば権力を長く持つと腐敗するってのが歴史が証明してる
今回はわかりやすく宗教と金でスキャンダルにもなってるわけなんで交代した方がいい
じゃないと自民は図に乗り続けて腐敗し続けるそんだけの話
例えば政権交代するとして立憲に期待するとか立憲に能力があるとかそういう問題じゃない
というか無能ばっかだから交代のオーバーヘッドで痛い目見るし民主のノウハウなんかなくなってるからものすごいうんざりするようなことがまた起こるのは確定なんだけど
腐敗よりコスト安いしいつでも「交代するからなボケが ちゃんとやれ」ってという緊張感があれば自民にまた戻ったとしても腐敗は遅延するってだけ
でも仮に自民と同じだけ立憲が与党張ればたいした差なんかないよ
で確実に立憲も腐敗する そん時は自民なのかは知らんがまた交代するだけの話
