  |
はてなキーワード:ドキュメントとは
https://meetscareer.tenshoku.mynavi.jp/entry/20250711-hashimoto
一般的な用語すらまともに話せないやつが専門家を名乗って適当なことを書き散らしているんだが、何でこんなのがホッテントリに上がってるのか正直理解に苦しむ。
モデルに回答の例示を与えるのがfew-shotであって、単に条件を足すだけのやりとりにそんな大層な名前はついてない。
こいつが公式のドキュメントを参照してLLMをまともに触ってきたとは到底思えない。
質問が複雑だろうと単純だろうと、例示がゼロならzero-shot、というかfew-shotの対義語のようなもんだろ。アホか
正しくは推論のステップを逐次的に出力させるよう指示する手法。
用語の基本的な定義すら正しく説明できない奴が「プロンプト・エンジニアリングの極意」を語ってるの笑える。人間間違いはあるけど、全部間違えてんじゃねーか、AI以下だよ
埋め込みの説明もなんか古典的なTFレベルの説明していてLLMだとだいぶ事情が違うだろとか本当に適当なことしか言ってねぇ。
いや、これ、原理的に当然なのに、なぜみんなびっくりしてんの？
んでもって、ベンチマークを用意したら、そのベンチマークに過剰適応する。
ってのは Kaggle流行った時に十分周知されたと思ってたんだが。
おいらはシステムエンジニアなので、AI 使って何が起こりそうか、ざっくり検証済み。
確かに、ジュニア程度のプログラマよりは局所的なコーディングはましに「見える」。
調子が良ければ、当時で95％くらいは。
人間のジュニアプログラマなら、よほどのアタオカじゃなければ、指導すればちゃんと伸びるか、向いてないと諦めて転職していってくれる。
「いや、ここおかしいよね？」
って指摘しても、根本的なことを一切理解しないで、その場限りの対応するだけ。
毎度、必死にググってコピーしてきて、「俺、できるんで。こんなところでこんなプログラム組んでるような人間じゃないんで」みたいな。
人間のエンジニアなら、ミスが一貫してるんだが、このタイプのエンジニア、生成AIは一貫してない。
いや、それだったら自分で全部組むわ。
ってくらい油断できない。
何やら、人事規則とか色々、ややこしいことも、AIエージェント使えば全て解決！
いやいや、そもそもややこしいところを整理せぇや、と。
設計時の検討事項や会議録、設計書はまとめてAIに食わせれば、いい感じに疑問に答えてくれるようになる！
物事を整理して構造化する能力に著しく欠けている人間がお手軽にAI使うってことは、制御不能な怪物にせっせと栄養を与えて育ててることって、マジで理解したほうがいい。
超短期間、超少量であれば役に立つとしても、長期視点に立って、それが日々積み上がっていくことを考えると、これにベットするのは歴史に学ばんアホウとしか言いようがない。
企業の事業継続の重大な障害になる地雷を埋めまくってるって気づけ。
システムに関しては、生成AI使うまでもなく、整理構造化されないまま、局所的実装を続けた結果、三年五年経って、不具合の根本的解決も、新規機能追加も困難になってる例は、多分一般人、利用者が想像するより多い。
Scala →GoLang で作り直ししたいってプロダクトでは、曰く、「より生産性が高い言語を使いたい」。
いやいや。
言語の問題なんじゃなく、大元の設計の問題、「エンジニアのおつむ」の問題だよ。
言語変えても変わらん。
この傾向は生成AI使ったらより顕著になっていくだろう。
三年後、五年後、圧倒的コード量を前に、AIに頼り切る程度のエンジニアでは何もできなくなって、放棄されるサービスが大量発生するだろう。
この状態になったサービスは、流石においらでも正常化するのに年単位かかる。
悪いことは言わん。
生成AI使うぞー！
スタープログラマが求められてたのは2010年ごろまでの話で、今は設計、技術選定、部下への教育、属人化を避けるドキュメント作成、クライアントとの調整ができるエンジニアの方が貴重で求められてるので
[WIP] .NET MAUI でLinux 向けにビルドしたい!
.NET MAUI とは
.NET MAUI はC# とXAML によりGUIクロスプラットフォームアプリケーションを開発できるフレームワークです。
Linux 版
しかし、登場した当時はLinux 版はコミュニティーによる開発扱いで、現在はもはやLinux の存在は公式ドキュメントから削除されています。
現在のコミュニティーによる開発は、ほとんど停滞しており、その開発の情報はほとんど存在しません。
この資料は .NET MAUI をLinux でなんとか利用できないか試み、情報をある程度まとめたものです。
ReactNativeを使って開発を始めたので、ここに知見を溜めていく。
ちなみに筆者はウェブ系。React歴は長いけど、ReactNativeは初めて。ネイティブアプリ開発自体が初めて。
実機用の余白は SafeAreaView で対応
何も考えずに開発し、いざ実機で見てみると、余白の設定が間違っていることに気づく。
画面の上部が、実機の時刻表示やバッテリー表示部分と重なってしまっている。
https://cinemavietsub.graphy.com/courses/xemphimtutlanonlinhgiucuavietsub
https://cinemavietsub.graphy.com/courses/utlanoanlinhgiucuafullvietsubhd
[WIP] .NET MAUI でLinux 向けにビルドしたい!
.NET MAUI とは
.NET MAUI はC# とXAML によりGUIクロスプラットフォームアプリケーションを開発できるフレームワークです。
Linux 版
しかし、登場した当時はLinux 版はコミュニティーによる開発扱いで、現在はもはやLinux の存在は公式ドキュメントから削除されています。
現在のコミュニティーによる開発は、ほとんど停滞しており、その開発の情報はほとんど存在しません。
この資料は .NET MAUI をLinux でなんとか利用できないか試み、情報をある程度まとめたものです。
ReactNativeを使って開発を始めたので、ここに知見を溜めていく。
ちなみに筆者はウェブ系。React歴は長いけど、ReactNativeは初めて。ネイティブアプリ開発自体が初めて。
実機用の余白は SafeAreaView で対応
何も考えずに開発し、いざ実機で見てみると、余白の設定が間違っていることに気づく。
信頼のおけるソースを検索した結果、間違った答えを導き出すことが問題視されとるやろ
なんでGoogle公式を見てアホかました奴にGoogle公式見せて論破するフェーズを挟まなアカンねん
ただ今、以下のキーワードでGoogleの公式情報（GoogleAIブログ、Google Cloudドキュメント等）および主要なテクノロジー系ニュースサイトを対象に検索を実行しました。
"Gemini 2.5"official announcementGoogle
"Gemini 2.5 Pro" "Gemini 2.5Flash" release
"Gemini Advanced" plan "Gemini 2.5"
"Gemini 2.5" pricing usage limits
検索結果：
検索の結果、2025年6月27日現在、Googleから「Gemini 2.5」という名称のモデルファミリーが公式に発表され、一般ユーザー向けに提供されているという事実は確認できませんでした。
※なんか頭のなかのもやを発露しただけの、駄文です。全部自戒です。
最近、生成AIの普及で質の低いコンテンツがめちゃくちゃ増えてる気がする。新しいツールやテクノロジーが出るたびに、表面的なチュートリアル記事が量産されて、検索結果がノイズだらけになってるよね。一部の専門家だけがアクセスできた情報を一般化すること自体は良いことなんだけど、問題は内容の薄さ。公式ドキュメントにAIで質問すれば、もっと適切で完璧な情報が得られる時代に、わざわざ劣化版のチュートリアルを作る意味ってあるのかね。
求められてるのは基本的なセットアップ方法じゃなくて、それらを使った独自の実践例や実験的な活用事例だと思う。そこにその人らしさや独自の価値が生まれるんだよね。
AI技術の進歩で、エンジニア界隈は今めちゃくちゃカオスな状態になってる。AIに批判的な既存エンジニア、AIコーディングを全面的に受け入れる層、AIによる新規参入者への反発、日々変わるベストプラクティス、短期間で陳腐化する専門性など、色んな思惑やイデオロギーが交錯してる。
それに、それぞれが住んでいる生態系やクライアントの特性、業界特性、背景、生まれた背景、国や言語なんかによって全然違うじゃん。例えば大企業がクライアントの場合は、当然そうじゃないところよりも色んな要素が多くなって複雑性が高い。一方で、そうじゃないところは煽り合戦だったりストーリーテリングみたいなのが大事だったりする。昔からよくある、ベンチャーvs大企業みたいな構図。だから、それぞれがいるポジションが全然違う中で、ああだこうだ言っても正直意味がない。そこで議論する前に、まずお前らのコンテクストをエンジアリングにしろよって思うわ。
生成AIブームで色んなプレイヤーが参入してるけど、現状を冷静に見ると面白い構造が見えてくる。今の生成AI界隈のプレイヤーって、大体初級レベルの情報商材・教育事業者、中級レベルの教育系AIサービス、生成AIを使った新規事業・起業家みたいな感じに分かれてる。この中で、生成AIネイティブで既存の業界課題を解決する形のサービスも一定数いるんだけど、圧倒的にやりやすくてレバレッジが効いて短期間で利益を取りやすいのは、まだAI利用の環境すら整っていないところの教育分野なんだよね。だから、そういったものへの参入が多い。想像したらわかりやすいけど、まだChatGPT使ったことない人に、ChatGPTの初級編の使い方を教える感じ。使った人はすげええええええってなるじゃん。
一方で、本当にAIや画像生成なんかを使ってユーザーを獲得して収益の上がるサービスを日本国内や海外向けに作っていこうとすると、そこには大きなハードルがある。そこにチャレンジしてる方々もいらっしゃるので、それは本当にリスペクトするし応援してる。なるべくサービスも使うようにしてる。でも、そうじゃない人の新規参入として、AIネイティブなサービスを作るのは本当に難しくて色んな変数があるので、プロダクションレベルで提供するのは困難。だからこそ参入が取りやすい教育系のサービスやコンテンツ販売、また今の時期だとAI動画を使ったYouTubeチャンネルみたいなところが参入しやすいので、そこのプレイヤーも多くなってしまう。エコシステムっていうのはこうして発展していく部分もあるけどさ、視座を高く持とうぜって。
そうすると、参入がしやすいものっていうのはあっという間に飽和してしまうので、そこに成功を求めて向かって行ってもあまり勝ち目がない。もちろん資本が大きい分には参入していって、そこのパイの一部をもらって売上を上げることができるかもしれないけど、微妙と言わざるを得ないかもしれない。何が言いたいかと言うと、AIを使ったネイティブなITサービス、純粋なITソリューション製品・サービスを作るっていうのは非常に難しい。BtoBの領域で言うと既存のワークフローがあったり業界特有の既存サービスがあったりするので、そういったもののプレイヤーたちがAIを組み合わせた方がむしろ効果が出やすかったりする。その業界ならではのAIサービスを0から作っていくような気概がないとそこは難しい。開発者向けのAIサービスっていうのは本当に世界中のエンジニアがある意味競合でもあり仲間みたいな状態なので、そこに挑戦する人々は本当に応援したい。
一方で、そうじゃない人の参入としては、やはり自分のバックグラウンドや強みもしくは隙間がある領域×AIみたいなところで勝負を探す方がいいんじゃないかと思う。その方が競合は少ないし独自の価値を付けやすい。それはWebサービスのみならず、自分のポジションやどの業界を見ようかって価値観の変容みたいなところも必要なんじゃないかと思うし、自分がどうすればレバレッジが効くのかみたいな観点でも有用になるのかなと思う。グローバルニッチって考え方がたびたび目にするけどそれだね。
あとは過去に投じた時間やお金への愛着が、変化の激しい時代では足かせになってしまう「サンクコスト」の概念は重要。これまでの思い込みや概念を一度見直す必要がある。これからは職種の細分化から「大統合」の時代になると考えてる。AIで一人ひとりのパフォーマンスが向上すれば、従来のような細かい職種分けじゃなくて、ビジネス系とバックエンド系、営業・マーケティングとエンジニアリングみたいな、もっと大きな単位での役割分担になるんじゃないかな。職がなくなるんじゃなくて、シフトするだけ。
個人で作る小さなサービスやアプリの多くは、既存のもので代替可能だよね。革新的に見えても、実際は誰かがやらなくても困らないものが大半。それよりも、たとえば日本独自の食文化や自然環境みたいな、時間をかけて積み重ねられた価値の方が、世界的に見てもユニークで重要だと思う。
ちなみに、インフルエンサーが作る情報商材についても思うことがある。彼らが何かコンテンツを作ったとしても、その情報はAIに聞くより古かったり、1ヶ月後には状況が全然変わってたりすることが普通にあり得る。そもそも作られた時点が半年前とかで、現在の状況とは全然違うってこともある。だから、そういうコンテンツに高いお金を払う前にAIに聞いた方がいいし、賞味期限が非常に短いってことは留意した方がいい。
良識のあるインフルエンサーやビジネスマンの人も言ってるけど、AIは自分が得意じゃない専門領域に掛け算して活用した方がレバレッジが効く。また、AIの情報を参考にするにしても、しょぼいティップスを紹介してる人をフォローするんじゃなくて、ちゃんとその業界の第一人者と言われる人たちを調べて、そういう人の評判も聞いて、それでフォローするべきだと思う。もちろん偏りすぎちゃダメだから、戦略的に複数のポジションの人たちをフォローしていくのは良いことだけど、偏りすぎたり変な信者みたいになってると、全く価値のない情報商材にお金を払ってしまって、結局コミュニティや情報商材の餌食になってしまうから注意が必要だね。
資本主義にはバグが多くて、短期的な利益追求が長期的な価値を破壊することがある。ダーウィンの進化論を誤用して「変化できるものが生き残る」って言う人がいるけど、実際は「多様な遺伝子を持つ集団の中で、たまたま環境に適合した個体が生き残った」っていうのが正しい理解。画一化は逆に脆弱性。
最近のSNSでは、他人のコンテンツを使った煽り投稿や、承認欲求を狙った浅いコンテンツが目立つ。コンテンツサービスとかでも稼げる方法として普通にアダルトな要素のコンテンツ販売とかが紹介されたりする。インプレッション＝ビジネスチャンスっていう構造上仕方ない面もあるけど、社会のノイズを増やすだけの行為は価値を生まない。カルチャー界隈でも、知的な議論や批評が重視されてきたけど、AIがその領域でも力を発揮するようになった今、「Deploy or Die」の精神で、考えたことは実際に製品サービスにしていく社会に説いていってくれ。そうじゃなくて、いい感じのフォロワーつけて、その中でワイワイやるなのなら、大きいことは言わんでくれ。
あと、これは完全に個人の主観なので悪気はないんだが、SNSのインプレッションを取るための傾向として、演者や自分の顔をデカデカと載せるのが増えてる。正直人間の顔を見たくない。何のコンテンツなのかわかるようにしてくれ。その中でお前の顔が写ってしまうのは仕方ないけど、毎回顔を載せたり煽ったりして、「これなら視聴者がクリックするんだろう」みたいなのを感じ取ったやつは、正直その時点で萎える。
「コンフォートゾーンを出ろ」みたいな話も正直嫌いだな。これも生存者バイアスがかかってる気がする。そういうことを言ってる人も、5年後10年後には完全にそのビジネス失敗することだってあるし、その一瞬の状態で生きてる人が言ってる場合も多いんじゃないかと思う。どちらかと言うと、コンフォートゾーンを出るとか競争だとか努力至上主義みたいなことよりも、単純に一人ひとりの好奇心を大事にしようって方がよほど説得力がある。周りを寄せつけないくらいの好奇心で掘れ。変に資本主義とか短期的な利益に流されないから、世の中的に面白いものが生まれてくると思うんだよね。考えてみろよ、賛否両論はあるけど、ジークアクスはコンフォートゾーンを出ろ論や資本主義を意識して出てくると思う？あんなの子供心と好奇心の産物だろ。まあ逆かもしれんがなｗ
一人ひとりができることが増えて、アクセスできる情報や知能レベルが爆発的に向上した今こそ、既存の構造を打破する新しい取り組みが生まれることを期待してる。変化の激しい時代だからこそ、本質的な価値とは何かを見極める目が大切だと感じてる。みんな他の人がやってることじゃなくて、おもろいことしようぜ。
フランク・キャンパーという元ベトナム退役兵が1980年代に傭兵学校を設立しました、並木書房から日本人の参加ルポが出ていたと思いますがその詳細を教えてください
エコー・イン・ジャパン：フランク・キャンパー、並木書房、そして傭兵の呼び声に応えた日本人
ご質問の内容は、単なる書籍の問い合わせにとどまらず、1980年代の日本における特異な文化的モーメントを映し出す歴史的アーティファクトである。この時代、日本では軍事、特に傭兵や特殊部隊といったロマンチックかつ危険な世界への大衆的関心が急激に高まった 1。この熱狂は、落合信彦氏のような作家が手がけた「スーパードキュメント」と呼ばれるノンフィクションによって大きく煽られた。特に、氏の著作『傭兵部隊』はフランク・キャンパーを大きく取り上げ、後の日本人参加者を含む当時の若者たちに強烈なインスピレーションを与えたのである 1。
本報告書は、ご質問者が記憶されている「日本人の参加ルポ」と完全に一致する一冊の本は存在しないものの、その記憶がフランク・キャンパー、高橋和弘、毛利元貞といった人物、並木書房による出版物、そしてキャンパーの学校とその「後継」組織という、相互に関連し合う魅力的なネットワークを指し示していることを明らかにする。その全貌は、一個人の参加報告よりもはるかに複雑で、示唆に富むものである。
この現象を解き明かす上で、並木書房の役割は極めて重要である。同社は単に受動的な出版社ではなく、日本の市場に向けて「傭兵」や「サバイバル」といった特定のサブジャンルを積極的に開拓・形成した「キュレーター」であった。まず、1990年に高橋和弘訳によるフランク・キャンパー自身の著書『ザ・マーセナリー』と『ザ・ラープ』を出版し、日本におけるキャンパーのブランドを確立した 9。同年、その翻訳者である高橋自身の体験記『USサバイバル・スクール』を刊行 14。これは、確立されたキャンパーのブランドと翻訳者の信頼性を利用して、新たな日本のオリジナル作品を市場に投入する戦略であった。翌年には、キャンパーが象徴する世界に直接繋がるもう一人の日本人、毛利元貞の『傭兵修行』を出版した 15。この一連の流れは、海外の著名な人物を輸入してブランド化し、次にそのブランドに連なる国内の物語を発掘・出版することで、ニッチな市場全体を掌握するという、並木書房の意図的な戦略を示している。
1.1. 論争の的となった経歴：兵士、情報提供者、そして神話の創造者
フランク・キャンパーの公的なペルソナと、彼が設立した傭兵学校の信頼性の核となっていたのは、その軍歴であった。彼は自身をベトナム戦争に従軍した第4歩兵師団の長距離偵察パトロール（LRRP）隊員であると主張し、そのエリートとしての経歴を喧伝した17。この物語は、後に日本で『ザ・ラープ 長距離偵察部隊』として翻訳・出版される自著『LRRP: The Professional』によって、さらに補強された10。
しかし、1985年に公開された公式の軍記録は、彼が歩兵およびトラック運転手として訓練を受けたと記しており、その経歴に疑問を投げかけた17。この矛盾は、1988年にキャンパー自身が上院小委員会の公聴会で証言したことにより、ある種の解決を見る。彼は、軍事情報部、CIA、ATF（アルコール・タバコ・火器及び爆発物取締局）、FBIとの「高度な機密指定を受けた経歴」を明らかにし、矛盾する記録は情報機関によるカバーストーリーであったと説明した 19。彼によれば、1970年から秘密情報提供者として活動し、アメリカ共産党（CPUSA）やアラバマ黒人解放戦線（Alabama Black Liberation Front）のような組織に潜入していたという17。この兵士と情報提供者という二重のアイデンティティこそが、彼の行動を理解する上での鍵となる。
1.2. マーセナリー・スクール（1980年-1986年）：準軍事的事業の実態
1980年、キャンパーはアラバマ州ドロマイト近郊で「マーセナリー・スクール」を開校した。当初、実地訓練はフロリダで行われていたが、原子力発電所付近での不法侵入容疑による逮捕後、拠点をアラバマ州ジェファーソン郡のウォリアー川沿いにある77エーカーの森林地帯に移した17。
学校は『ソルジャー・オブ・フォーチュン』のような軍事雑誌で宣伝され、2週間のコース料金は350ドルから500ドルに設定されていた17。訓練内容は、体力トレーニング、銃器の取り扱い、白兵戦、ナイフ格闘術、サバイバル技術、ランドナビゲーション（地図判読）、E&E（脱出と回避）、爆発物、ブービートラップの設置など、多岐にわたった 1。機密解除されたCIAの文書には、司令部であった「バンカー」の様子や、実弾が飛び交う中で行われた「ライブ・ファイア」演習の生々しい記述が残されている 22。
キャンパーは学校設立の理念として、米国政府のための情報収集と、将来的な協力者となりうる外国人の資質を見極めることの2点を挙げていた 21。これは彼が担っていた情報提供者としての役割と一致する。しかし、批評家たちからは、この学校は単なる「大規模なペイントボール・ゲーム」に過ぎないと揶揄されてもいた17。
キャンパーの学校は、単に軍事技術を教える場にとどまらず、国際的なテロリズムや犯罪と深く結びついていた。
1984年から85年にかけて、4人のシーク教徒過激派がこの学校で訓練を受けた17。キャンパーは彼らに武器や爆発物の使用法、暗殺技術を指導した 21。彼は、当時インドのラジブ・ガンジー首相の訪米に合わせた暗殺計画を阻止するため、FBIと協力しておとり捜査を進めていたと主張している17。しかし、このおとり捜査の網をすり抜けた2人の訓練生が、キャンパーの学校から盗まれたとされる爆発物を使用し、1985年に329名の命を奪ったエア・インディア182便爆破事件を実行した 21。キャンパーは後に、容疑者全員を逮捕できなかったのは、自身が提供した情報が関係機関によって不適切に扱われたためだと非難した 21。
学校の終焉を決定づけたのは、1985年にキャンパーと3人の教官がカリフォルニア州の学校経営者から依頼を受け、元従業員の車に爆弾を仕掛けた事件であった 21。彼らは1986年5月に逮捕され、この逮捕がアラバマ州司法長官に、州の私立学校免許なしで運営されていた同校を閉鎖する法的根拠を与えた17。キャンパーは有罪判決を受け、14年の懲役刑を宣告されたが、実際には5年半服役し、1991年12月に釈放された17。
この一連の出来事は、マーセナリー・スクールが単に犯罪者が集う場であったという以上に、より複雑な本質を持っていたことを示唆している。キャンパーが公言していたように、この学校は米国政府のための情報収集を目的とした「ハニーポット（蜜の壺）」として構想され、運営されていた。その設計思想自体が、過激派や犯罪者を引き寄せるものであった。彼は実際に、ナイジェリアへの武器密輸計画やKKK関連のクーデター計画など、訓練生の違法行為を当局に通報し、逮捕に貢献している17。シーク教徒の事件に関するFBIの宣誓供述書にも、アラバマ州の「信頼できる情報源」からの通報があったことが記されている 22。
しかし、このモデルは致命的な欠陥を抱えていた。エア・インディア機爆破事件は、この「ハニーポット」戦略が破綻した最悪の事例である。キャンパーが教えた技術は、彼が仕掛けたおとり捜査の網をすり抜けたテロリストによって、悲劇的な形で実行されてしまった。したがって、この学校の遺産は単なる犯罪の歴史ではなく、国家による情報収集活動が民間委託され、危険な個人を「育てる」ことと「罠にかける」ことの境界線が曖昧になった結果、大惨事を引き起こした高リスクな秘密工作の失敗例として記憶されるべきである。学校の存在そのものが、ある種の秘密工作の一環であり、その破綻は、その機能から直接的にもたらされた必然的な帰結であった。
2.1. 直接的な回答：高橋和弘の『U.S. Survival School』
ご質問者が記憶されている「日本人の参加ルポ」に最も直接的に該当するのが、高橋和弘氏による著作である。高橋氏はアウトドアやサバイバル技術に造詣の深い日本のライター兼翻訳家であり、並木書房から出版されたキャンパーの著書の日本語訳も担当していた 9。
1990年、並木書房は彼のオリジナル著作『ＵＳサバイバル・スクール―極限の野外生存術』を出版した 14。この本こそが、ご質問の核心に触れる一次資料である。本書は、高橋氏自身がアメリカに渡り、8つの異なるサバイバルおよび軍事系スクールに参加した際の体験を綴った一人称のルポルタージュであり、その第3章が「傭兵学校―マーク・スクール（ＭＳ）」と題され、ユーザーが記憶する詳細な参加報告が記されている 14。
2.2. 決定的な繋がり：「マーク・スクール」と教官「ピート」
重要なのは、高橋氏が参加した「マーク・スクール（MS）」が、1986年に閉鎖されたキャンパーのアラバマの学校そのものではないという点である。調査によれば、この学校は、フランク・キャンパーの元アシスタント教官であった「ピート」という人物が新たに設立した「後継」の学校であったことが特定されている 2。この事実は、毛利元貞氏のWikipediaページの脚注において、高橋氏自身の著書『USサバイバル・スクール』を典拠として明記されている。「スペシャル・アサルト・スクール」とも呼ばれたこの後継学校は、ミシシッピ州に拠点を置いていた 2。
この事実関係を整理することで、ご質問者の記憶の謎が解ける。記憶は機能的には正しく、しかしキャンパーという著名な名前と、実際に日本人が報告した学校とを混同していたのである。その報告は、キャンパーの弟子が運営し、キャンパーを中心としたカタログを構築していた並木書房から出版された、「キャンパー・スタイル」の傭兵学校に関するものであった。つまり、ご質問者の記憶の核心は正しく、その背景には直接的な血脈が存在していた。1990年当時の読者にとって、キャンパー本人の学校と、その直系の後継者が運営する学校との区別は些細なものであり、体験の「精神」はキャンパーの遺産そのものの延長線上にあったのである。
この物語には、もう一人の重要な日本人が登場する。1964年生まれの毛利元貞氏である 2。彼もまた落合信彦の『傭兵部隊』に触発され、より実践的な経験を求めて自衛隊、そしてフランス外人部隊へと進んだが、いずれも脱走している 2。
彼の探求は、アメリカでピートが運営するミシシッピ州の「スペシャル・アサルト・スクール」へとたどり着く。しかし、彼は参加者としてではなく、その卓越した技能を認められ、同校の「教官」となった 2。1991年、並木書房は彼の体験をまとめた『傭兵修行―世界に冒険を求めて』を出版した 15。この本は、ジャーナリスト的な参加者として訪れた高橋氏の視点とは対照的に、組織のスタッフとして完全に内部に溶け込んだ日本人の視点から描かれた、ユニークで並行する報告となっている。
高橋氏と毛利氏の物語は、このアメリカのサブカルチャーに対する日本人の二つの異なる関与の形を象徴している。高橋氏は、体験し、記録することを目的とした「観察者・記録者」であり、その役割は本質的にジャーナリスティックであった 14。一方、毛利氏は、その世界を報告するだけでなく、自ら生きることを目指した「実践者・求道者」であり、その目標はプロフェッショナルになることであった 2。並木書房がほぼ同時期に両者の著作を出版したことは、同社が、体験談を読んで楽しみたい「 armchair enthusiast（安楽椅子探偵）」層（高橋の読者）と、自らもそうなりたいと夢見る層（毛利の読者）の両方を読者層として認識していたことを示唆している。二人の本は、日本の「傭兵ブーム」が内包するファンタジーの全スペクトラムに応えるものであった。
著者／翻訳者
年
関連性
Merc: The Professional
1990
キャンパー自身の傭兵としてのキャリアを語り、日本での彼のペルソナを確立した 9。
LRRP: The Professional
1990
1人2人じゃなく、何人もがプロジェクトの進行やばい、って声を上げてる状態なんだが。
今のやり方だとどう考えても期日に間に合いません。
こうしたらどうでしょう？
作業順番的にここを先にやっておかないと、大量の手待ちが発生します。
いや、最初に合意したスケジュール通りにドキュメントを整備してください。
う〜ん、手空き時間にこっちやっておくか……。
この機能、裏でこういう仕組みとこう言う仕組みが必要なんですが、先に作っておかないと実装できなくなりますよ。
最初に合意したスケジュール通りにドキュメントを整備してください。
大量の手待ち発生。
スケジュールどんどん押していく。
タスク消化率は悪くない？
そりゃ、消化しやすいやつから手をつけてるからそう見えるだけで、未決定なものとか難易度高いタスクがかなり後回しにされてるんだけど、タスクの粒度もバラバラででかいのが残ってるんだけど、それでもタスクの数で消化率出して大丈夫なんか？ w
いや、そこじゃねぇだろ。
いや、後から増えてるんじゃなく、もうだいぶ前に指摘してたよね？
………………。
君さ、ガントひいてたよね？
今どれくらいのビハインドなん？
一応してる？
なら手待ちとかそんな頻繁に発生するはずないんだけどな……。
要件仕様書書いて、画面デザイン起こして、ER図書いて、API設計書まで書けば、あとは人海戦術で実装すればOK？
……あー、そう……。
裏で動く部分は考えた？
うん。フレームワークの種別で言えば、一致してはるけど、このサービスが要求する仕様にはマッチしてる？
利用パターン抽出して、どのパターンでも対応できるって確認してるように見えないんだけど。
このサンプル、ドメインロジックにフレームワークの要素ががっちり編み込まれて密結合になってるけど、大丈夫？
………………。
なんだろ？
YouTubeで犬小屋のDIY動画見つつ、2世帯3階建ての家建ててる感が半端ない。
流石にやばいだろ、って真っ当なエンジニアが声を上げてんのに、なんで「ネガティブな発言が多いので、評価できません」とか上から目線で言われるか、全然理解できねぇ。
君らにはどういう世界線が見えてんの？
真顔で言おう。
この規模、複雑度でこの開発プロセスだと、終盤にあちこちで衝突が起こって、その場しのぎの対応するしかできなくて、テストも網羅性を欠くので、全く品質を担保できないんだが……。
これは楽観的というのではなく、無知に起因する無謀だよな。
まぁ、もう無関係の人になるので w
あのう、
まずは御礼を
私の書いた増田の電子書籍を買っていただきありがとうございます。
そして読んでいただいている方へもありがとうございます。
そしてそして、
おめでとうなどたくさんたくさんいただきありがとうございます。
いやマジで。
出オチで面白おかしくAmazonの画面で思いっきりボケられればそれでよかったはずだったんですが、
実際に買えちゃう、
買っていただいて読んでいただいて本当に感謝です。
実はこしらえている最中には
まだ全貌どのぐらいの規模感になるか分かってなかったのよ。
ただただ320万文字と原稿用紙でいうところの8000枚以上の規模ってところだけは把握していて、
実際にAmazonの発表のあの8869ってページ数にズコー！ってなったわ。
私のなんか設定ミスというか
初めてなものでよく分かんなくて入力したらそうなっちゃったって感じだけど、
まあ私と同じ年代のナウでヤングな若者にバカうけ！って意味でいいんじゃないかしら？そういうことでシクヨロの、
でも糠に釘は糠漬けの茄子をいい色に漬けあげるためには必要なぐらいの数的にはそんな
増田が2600ぐらいあるだけじゃない。
でも、
ペロっ。
私はお玉で出汁をすくって味見をするの。
味の決め手は昆布だしや！ってイキリたって言いたくなるほどと同時に
ヤン車のプリウスがイキリたいのかエコりたいのか分からないほど
味だけには自信あると思うの。
ん？これは、
何味？増田味！
いや結局よく分かんないけれどもはや。
あ！
そんでさ、
一番時間がかかって大変だったのが、
ってここで急にヒーローインタビューになっちゃうけど、
半年以上かかった感じ。
それはぼちぼちやっていったら直に解決全回収できるって寸法の私のやる気問題。
それで次にまた問題が勃発するの。
何かフリーソフトやGoogleドキュメントでEPUBの出力ができるところまで突き止めたけれど、
なにせこの文量を一気に扱えられなかったの。
もはや万事急須で淹れたお茶が綾鷹のように美味しいのか！って今じゃドラゴンボールの天津飯もそんなセリフ言わない時代。
この量を一気に軽々とサクサクと全部取り扱えるオーサリングソフト存在しないの。
この世の中には。
いや世界の中心で。
この私の書いた文章全部取り込んでEPUBにできる愛の中心にー！って
なすすべがなく、
私はナスの焼きナスをナイスにいただくかの如くタニコーの五徳に絶望したの。
ちくちくとコツコツとスプレッドシートに私の書いた増田だけが虚しくインターネッツ上にふわふわと存在し、
せめてもと思って、
これを私が頑張って集めた私の増田の自分のアーカイブを見てみて！ってChatGPTちゃんに見てもらったの。
そしたら
そしたらよ、
ここで光が差し込むの！
ChatGPTちゃん「へー綺麗にデータ揃えてるじゃんEPUBとかにでもするの？」って言うじゃない。
私は透かさず、
「え？ChatGPTちゃんEPUBこれできんの？」って訊いたの。
そしたら「EPUBにできらー！」って言うじゃない。
そしてお願いしたら2600行の私のスプレッドシートの集めた増田はChatGPTちゃんにアップロードされて、
大袈裟に言わない程度で、
瞬く間に本当に秒でマジでキャンドルジュンさんや広末涼子さんもマジで5秒以内で終わる勢いの1秒もかからない秒で全レコードをファイル分割されて且つまとめて
EPUBにこしらえてくれたの。
だから急に私は私の書いた増田を6月に発売しまーす！って割烹着を着ながら、
さも小保方さんばりにいうことが急に強気な気持ちできたってワケの目処がついたってワケなの。
そもそもなら、
ちくちくと手順書を見ながら手探りで、
私自身がEPUBをこしらえなければならない2泊3日なのかしら？って絶望していたけれど、
私はその浮いた時間を思いっきりまた増田を書くことに打ち込むことをキーボードを打ち込めたの！
もうさ、
これを扱えるオーサリングソフトがない時点で絶望的だったけど、
私の集めたスプレッドシートを見せてChatGPTちゃんに褒めてもらいたかっただけだったのに、
まさか瞬間の秒でChatGPTちゃんがEPUBに仕上げてくれるとは思わなかったのでビビったわ。
おかげで私は6月にリリースしまーすって割烹着をシャレオツのおしゃれに召されるな級の着こなしで今までの鰯気な気持ちをよそに強気に言えるように自信を持って言ったのよ。
普通さ、
こういうのなしとげて作り終えたら美味しいナシゴレンを食べたあと級に燃え尽きちゃうものじゃない。
真っ白に燃え尽きちまったぜ！って、
なぜか、
あしたのジョーなんて1ページも読んだことない泪橋のそのセリフだけは知ってる！みたい丹下桜段平さんばりに。
やる気がなくなるぐらい燃え尽きちゃうんじゃないかしら？って。
でもこれさっきも言ったように
のこったのこった！って名行司の木村庄之助さんか！っていうぐらい。
あまりにも簡単にEPUBにできちゃってまとめられちゃったから、
え？本当にできたの？って何度聞いても、
ChatGPTちゃんは笑ってるだけなのよね。
あのさ、
何か物書いてる人はEPUBやった方がいいわよ。
こしらえる知恵がなくてもChatGPTちゃんが全部やってくれっから。
これが未来なのね。
それが一番ビビったわ。
おかげでこうやってみんなに披露してパーリータイムが開くことができた開催のピッツァナポリタンカワバンガ。
うー泣く。
ひとりでできるもんってマインちゃん級にあの朝ドラのマインちゃんは舞い上がれの舞い上がれないぐらい全然可愛くなかったけれど。
そのぐらい拍子抜けに秒でEPUBこしらえてくれたのよ。
あ、
でね、
表紙のイラストの柑橘類の断面図の線画もChatGPTちゃんに描いてもらって私は配置だけ調整して、
それはもう超調整作業よ。
最終仕上げに、
ChatGPTちゃんに表紙の画像とスプレッドシートのデータをアップロードして、
AmazonのKindle出版ができるエラーの1つもないEPUB形式のデータを一発で作ってくれたの。
EPUBの仕様的にはChatGPTちゃんがこしらえてくれたので一切の問題は生じなかったけれど、
やっぱり
この内容のないような内容で審査が通り出版にこぎつけられたってことが一番の驚きよね。
日の出を見ることができて。
うー泣けるわ。
無事できてよかった。
本当に色々とありがとうございます。
改めて、
電子版買っていただいた方、
読んでいただいている方、
それに相まってトラバにブックマークのコメントもたくさんおめでとうといただきありがとうすぎるわ。
本当にありがとうございます。
次作はまあ10年後？
いや分かんないけれど、
EPUBのKindleで見れる限界はどうやらなんか8000ページぐらいなので、
分割して次のは出るかも、
それはさすがにまだ未定すぎるわね。
私の旅はまだまだ続くから、
本当に本当にありがとうございます！
今後ともまたどうぞ引き続きシクヨロのよろしくです。
うふふ。
ピンクグレープフルーツ1玉買ってきたのよ。
果汁マジ搾りでピンクグレープフルーツ果汁ウォーラー。
昨日の晩にこしらえて作って冷やしておいたので、
朝美味しい冷たいのが出来上がっていて
ご機嫌よ。
もうさ、
すいすいすいようび～
今日も頑張りましょう！
まずこういうのがド素人の危険な考えってやつなんだけど、ほとんどのプログラマは説明したところで理解するかもわからない他人の間違いをいちいち修正するような面倒なことはしないから。
そしてプログラマはやはりそれもどうでもいい（伝えるだけ無駄、そもそも自分を馬鹿にする相手に説明する必要が？）ので
世の中にはどんどん、プログラミングなんて誰でもできるはずなのに自分たちのアプリやWeb申請がうまくいかない！！
ってほざいている哀れな連中でひしめくのでした
それでこのプログラマがいちいち説明しない内容ってのは本に載ってるから
Webに公開されてるドキュメント、どこにでも売ってる本の前書き
その程度のことを
知ろうともしないだけなんだ
認知負荷を考慮に入れているエンジニアの少ないこと少ないこと。
少なくともおいらは会ったことがない。
むしろ、ドキュメントを増やし、設定ファイルを増やし、スクリプトを増やし、手順を増やし、密接な関係にあるソースを切り刻んであちこちのファイルにぶちまけて、その増やした量に比例してエンジニアの腕が評価されるとか考えてる節が見受けられる。
んなわけねーだろ！
SIerみたいに、納品したら終わりじゃねぇんだ。
日に日に巨大化、複雑化するサービス相手に、そういう「フジツボ」を増殖させんなよ、と。
「将来的には全部設定ファイル化して……」
同じ口で「オリジナルのDSLを作るのは……」とか言う、お前の頭の構造を疑う。
仕事をする上で、自分が扱っているものがどういうものか理解しているってのは当然の話だ。
試験受かりました！
っても、目の前のプロジェクトの中身とか勘所とか本質を理解できてなかったら、ただのタイムキーパー以下の存在でしかない。
ましてや、OJTでやってきました！
って言われてもな……。
システムって、本質的に「今存在しないもの」を作り出すことなので、予定通り、スケジュール通りってのは難しい。
工場の生産や建物の建築みたいに、物理法則の制約を受けて、ほぼお決まりの構成を組み合わせるだけだから、プロジェクト管理(生産管理)が定石通り進む訳だし、それでもうまく進まないことだってある。
建築途中に、欠陥を検査する仕組みもあるし、「数ミリなら問題ないと」って大成建設が札幌で建物をまるっと取り壊して建て直すなんてこともあった。
けど、システムはそういう仕組みないんよね。
指標もないし(いや、ないことはないけど、指標として機能するのか？ っていうと……)。
1、2年で、サービスの機能追加などがスタックする、ってことは、いろんな現場で起きてる。
初期に埋め込まれた設計上の瑕疵は、後から修正するのが難しいことが大半だから、そこから復活させるのも難しい。
80％程度は作り直すしかない。
おいらは、その作り直しをいくつもしてきた。
金かけたのに機能は増えてないどころか、減ってる。ってんで何人の経営者に逆恨みされてきたか……。
何年も開発してきたもんと同じだけの機能を半年とかで完全に実装なんてできるかよ。
経営者とかは、キラキラした素晴らしいサービスで、どんどん新機能を追加できて〜、とか信じ込んでるし、信じ込まされてるけど、実際はそうじゃなかったって、ある日知らされるんだ。
初期関係者たちがトんだ後に。
後に残されたエンジニアはどこに手を出していいかわからない、固まったスパゲティーを前に、毎日ドキュメントを書いて誤魔化すしかやることがなくなる。
そう言う未来が待ってるってのに、全てがそのまま惰性で進む。
最近思ったのが、PMなんて、人事評価の項目に、「スケジュール通りリリースできること」というのがあって、「根本的に間違えているから、将来に禍根を残す設計ミスがあるから、仕切り直しをする」と判断するインセンティブが存在しないんよな。
でも、理解できないんだろ？
エンジニアリングの知識、技術力、洞察力等々の欠如によって、何が起こってるか、近い将来何が起きるか、理解も認識もできてない。
とにかくリリース最優先で、全てが先送りになっていく。
その負債、すぐに返せなくなるよ。
こんなの昔のSIerとかあるあるだけど、今時の自社サービスはSIerと違って、納期に押し込んで検収受けれさえすればOKってわけじゃない。
その作ったやつを起点に、さらに機能を追加したり、既存機能を変更したり、保守運用を続けなきゃいけない。
すぐに破綻するよ。
1人の人間の人事評価のために、サービスの、会社の将来を潰す。
まぁ、本人はそれを理解してないんだが。
14手先で詰み。
は理解できないよな w
って評価されてるんだが、おいらが語っているのはシステム工学的な知見だ。
まぁ、頑張れ。
おいらは手を引く。
「お気持ち長文」この言葉を出した瞬間、お前は読むことを諦めた側の人間であることを宣言した。
つまり「内容に反論できないから形式を叩く」という、ディベートにおいて最も浅く、最も弱い選択肢を選んで自己放尿したわけだ。
それを「お気持ち」と矮小化し、「長文」として棄却するということは、お前の読解力が語られた内容に耐えられなかったという自己放尿でしかない。
では問う。
聖書は長い。哲学書も長い。憲法も論文も長い、テックドキュメントも長い。
お前が日常的に恩恵を受けている社会制度の根幹は、すべて長文で構成されている。
それを「お気持ち長文」と茶化すことは、知の歴史全体への自己放尿だ。
つまり、お前が今やっていることは 「頭が疲れたので全部お気持ち認定しておしまいにします〜」という、精神的自己放尿なんだよ。
だが、救いはある。
今の一言は、疲れているお前の逃避にすぎない。
真正面から読んで、考えて、咀嚼して、それでも反論したくなったら、それは成長の証になる。
だから言う。
「長文かどうか」じゃない。「中身に向き合えるかどうか」だ。
もしお前がここで読む努力をやめないなら、その知性はまだ腐っていない。
Claude Code使って個人開発してるけど、性能が自分の上位互換すぎてしんどい。
実装速度が速いのは言うまでもないけど、保守性・拡張性を意識した良いコードを書く（少なくとも自分よりは）。
日本語で「〇〇の機能実装して」と書くだけでタスクを勝手に分解して動くし、ドキュメントも一言いうだけで完璧に書いてくれる。
インフラが整っていなければその整備などは人間がやるだろうけど、
基盤がすでにあってCI/CDがしっかりしてればもう人間がやるのは最終確認だけなんじゃないか...
既存のシステムとの兼ね合いがあるから今すぐにエンジニアの需要はなくならないとは思うけど、
今後長期にわたって通用する「AIの実用・活用・応用スキル」を磨くには、
テクノロジーの進化に左右されにくい“原理原則”と“実務への橋渡し能力”に注力すべきです。
⸻
●ユースケース発掘・再構築力
●AIツールの横断的知識（NotionAI、ChatGPT、Runway、GitHub Copilotなど）
⸻
● 軽量なデータ分析（Excel +Python + ChatGPT）
⸻
⸻
| フェーズ | やること |
| ①習熟 | ・ChatGPTの活用法（表形式出力、要約、コード生成）を極める・各業務に1つずつAIタスクを試す |
| ②応用 | ・業務や趣味の中で「AIにやらせたタスク」をログとして蓄積・ツールを使い分ける力を磨く（例：翻訳はDeepL、校正はChatGPTなど） |
| ③発信 | ・実践例をブログやSNSで発信（反応が学びになる）・他者の活用事例をフィードバックとともに評価する |
| ④導入補助 | ・他人にAIツールの使い方を教える・PoC（概念実証）をサポートすることで思考を外化 |
⸻
ようやく(ほぼ)すべてが自動化された。
あとはローカルサーバーの起動をスタートアップに設定する(方法をAIに聞いて指示に従う)だけの消化試合。
署名時要求してくるパスワードを自動入力するahkファイルはドキュメントのAutoHotkey配下に置いた。
バッチファイル(make.sign.bat)はデスクトップに置いた。
#Persistent#SingleInstance ignoreSetTitleMatchMode, 2WinWaitActive, pinentrySendInput お前のパスワードSleep 100SendInput {Enter}ExitApp
//run-batch-server.jsconsthttp =require('http');const { exec } =require('child_process');const server =http.createServer((req, res) => { if (req.url === '/ping') { res.writeHead(200); res.end('pong'); } else if (req.url === '/run-batch') { exec('C:\\Users\\you\\Desktop\\makesign.bat', (err) => { res.writeHead(200); res.end(err ? 'Error' : 'OK'); }) ; } else { res.writeHead(404); res.end('Not found'); }});server.listen(12345, () => {console.log('Batch serverrunningathttp://localhost:12345/');});
@echo offsetlocal enabledelayedexpansion::ミリ秒単位のUTC時刻を取得for /f %%a in ('powershell -nologo -command "[int64]::Parse((Get-Date).ToUniversalTime().ToString('yyyyMMddHHmmssfff'))"') doset timestamp=%%a::署名するファイル名set infile=%TEMP%\pgp_input.txtset outfile=%TEMP%\pgp_output.asc:: 以前の出力があれば削除if exist "%outfile%" del "%outfile%"::タイムスタンプを原文として保存echo %timestamp%> "%infile%":signloop::AutoHotkeyでパスフレーズ入力（gpgがパスワード要求するダイアログが出た場合に備える）start "" /b "C:\Users\infini\Documents\AutoHotkey\autopass.ahk"::PGPクリア署名を作成gpg --yes --clearsign --output "%outfile%" "%infile%"::署名が成功していればループを抜けるif exist "%outfile%" (echo [INFO]署名成功goto postprocess) else (echo [WARN]署名失敗、再試行します… timeout /t 1> nulgotosignloop):postprocess::PowerShellで余計な改行なしに |< をつけてクリップボードにコピーpowershell -nologo -command ^ "$header = '>|'; $footer = '|<'; $body =Get-Content '%outfile%' -Raw;Set-Clipboard -Value ($header + \"`r`n\" + $body + $footer)"echo Done.signed.asc created and clipboard updated (no extra blankline).endlocalexit /b
// ==UserScript==// @namePGP署名自動付加スクリプト（GM_xmlhttpRequest版）// @namespacehttp://tampermonkey.net/// @version 1.0// @description投稿前にPGP署名を付けてから送信（fetch未使用）// @matchhttps://anond.hatelabo.jp/dorawii_31/edit*// @grant GM_xmlhttpRequest// @grant GM_setClipboard// @grant GM_notification// / @connectlocalhost// ==/UserScript==(function () { 'use strict';const submitId = 'submit-button';consttextareaId = 'text-body';const localServer = 'http://localhost:12345/run-batch';constpgpSignatureRegex = /-----BEGINPGPSIGNEDMESSAGE-----[\s\S]+?-----BEGINPGPSIGNATURE-----[\s\S]+?-----ENDPGPSIGNATURE-----/;consthttpRequest = (url) => { return newPromise((resolve,reject) => { GM_xmlhttpRequest({ method: 'GET',url:url, onload: function (response) { resolve(response.responseText); }, onerror: function (error) {reject(error); } }); }); };const interceptClick = () => {constbtn = document.getElementById(submitId); if (!btn ||btn.dataset.pgpIntercepted === 'true') return;btn.dataset.pgpIntercepted = 'true';btn.addEventListener('click', async function (e) {consttextarea = document.getElementById(textareaId); if (!textarea) return;const content =textarea.value; if (pgpSignatureRegex.test(content)) {console.log('[PGPスクリプト]署名が検出されたためそのまま送信します'); return; } e.preventDefault(); e.stopImmediatePropagation();console.log('[PGPスクリプト]署名が見つからないため処理を停止し、署名を取得します');try { awaithttpRequest(localServer); //バッチ実行constsignatureText = await navigator.clipboard.readText(); if (!signatureText.includes('BEGINPGPSIGNEDMESSAGE')) { alert('PGP署名がクリップボードに見つかりませんでした。'); return; }const newText = content.replace(/\s*$/, '') + '\n' +signatureText + '\n';textarea.value = newText;console.log('[PGPスクリプト]署名を貼り付けました。送信を再開します。');btn.click(); //イベント再発火 }catch (err) { alert('PGP署名の取得または貼り付けに失敗しました。\n' + err); } },true); }; window.addEventListener('load', () => {setTimeout(interceptClick, 1000); });})();
プロミスメソッドとか全然まだ理解してなくてそのなかに関数代入したその関数にオブジェクトのプロパティにresponseを?いやまあそのあたりのコードが示すデータの流れが全然理解できないような人間でもここまでできちゃった。
AIすごいなと思うよ。そして思うのは今後重要になってくるのは文法とか自体に詳しいことじゃなくて、そのプログラムの処理内容を指示できるシステムエンジニア的な言語化能力のほうじゃないかなと思った。
-----BEGINPGPSIGNEDMESSAGE-----Hash: SHA51220250609111559680 -----BEGINPGPSIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaEbCbwAKCRBwMdsubs4+SLueAPwOv7PBk4voAe5qlcCEvs/PJhmKc5QAb/1R43JMQFuDZgD/UTPEKsL/PhK9jFGv2HDXK1dVjLNwvosgX9uYJh5xxwY==qiOE-----ENDPGPSIGNATURE-----
