OxideがLLMを活用する方法

 (rfd.shared.oxide.computer)
4 ポイント 投稿者 GN⁺ 2025-12-08 | 1件のコメント | WhatsAppで共有
  • 大規模言語モデル（LLM） は業務の進め方を根本的に変えており、Oxideはこれを組織内でどのように使うかを明確に定義している
    • Oxide はオンプレミスデータセンター向けに統合ハードウェアおよびソフトウェアを構築するオンデマンドコンピューティングインフラのスタートアップ
  • LLM活用の中核原則として責任、厳密さ、共感、チームワーク、緊急性のバランスを提示
  • 文書の要約・理解、コードレビュー、デバッグなどに有用である一方、執筆やコーディングには人間の判断と責任が必須
  • LLMが生成した成果物は常に人間がレビューし責任を負う構造で維持すべき
  • OxideはLLM利用を推奨するが、製品・顧客・同僚に対する責任感を前提としている

LLM活用の価値基準

  • OxideはLLM利用を組織のコアバリューに照らして評価する
    • 責任（Responsibility）：LLMはあくまでツールであり、成果物の責任は全て人間にある
    • 厳密さ（Rigor）：慎重に使えば思考を精緻化できるが、だらだら使うと思考の質が低下する
    • 共感（Empathy）：言語の受け手と書き手の双方が人間であることを認識し、人間中心のコミュニケーションを維持することが必要
    • チームワーク（Teamwork）：LLM利用が同僚同士の信頼を損なわないよう注意し、利用している事実を公開しても責任回避に見えないようにする
    • 緊急性（Urgency）：速度向上が可能であっても、他の価値を犠牲にしてはならない

LLMのさまざまな活用方法

読者としてのLLM

  • LLMは文書要約と質問応答に非常に優れており、大量の資料を短時間で理解できる
  • ただしデータプライバシーを確保する必要があり、アップロードした文書がモデル学習に使われないよう設定する必要がある
  • 文書理解補助ツールとしては有用だが、自分で読むべき場面を代替してはいけない

編集者としてのLLM

  • 完成した文書の構成・文体の改善に効果的で、後半工程で活用すると有用
  • しかしLLMは過度にポジティブな反応を示す傾向があり、批判的分析が不足することがある
  • 下書き段階で使うと、作成者の独自の声を失うリスクがある

ライターとしてのLLM

  • LLMが生成した文章は、陳腐で自動生成の痕跡が明確な場合が多い
  • 自動生成された文章は、思考の誠実さと読者の信頼を損なう可能性がある
  • 読者は作成者が内容を理解していることを前提としているが、LLMの文章はその前提を崩す
  • Oxideは、メンバー全員がライティング能力を持っていることを前提に、LLMをライティング主体として使わない
  • ただし、アイデア整理や補助ツールとしては限定的に活用可能

コードレビュアーとしてのLLM

  • LLMは特定の種類のコード問題の検出に有用だが、人間のレビューを代替できない
  • 提案が非論理的だったり文脈を見落とす可能性があるため、補助的なツールとしてのみ使用

デバッガーとしてのLLM

  • LLMはデバッグのアイデアを引き出す「ラバーダック」役割として使える
  • 実際の問題解決能力は限定的だが、新しいアプローチを思いつくきっかけとして有用

プログラマーとしてのLLM

  • LLMはコード生成能力が非常に高く、実験的・補助的なコーディングに適している
  • 製品コードに近づくほど検証と責任が重要になる
  • LLMが作成したコードは**作成者自身が直接レビュー（self-review）**を行う必要があり、同僚レビュー前に必ず確認が必要
  • コードレビュー中に全面再生成で対応する行為は禁じられており、反復レビューが不可能になる
  • コード生成時にも責任、厳密さ、共感、チームワークを維持する必要がある

運用とガイドライン

  • LLM利用の技術的な詳細と社内ガイドラインはGitHubの内部文書に整理されている
  • OxideはLLM利用を推奨するが、責任ある活用を前提としている
    • 製品品質、顧客への信頼、同僚間の協力に対する責任意識を最優先にしている

関連記事

1件のコメント

 
GN⁺ 2025-12-08
Hacker Newsの意見

  • Bryanの記事はバランスが取れていて現実的な視点を示している
    Oxideはジュニアエンジニアを採用していないため、RFDにその観点が抜けていたのだと思う
    Bryanは30年以上にわたり難しいソフトウェアとハードウェアを扱ってきたエンジニアで、"本当に難しいプログラム(OS)"を完成させた経験がある
    彼のLLMの扱い方は、2025年のジュニアエンジニアとは大きく異なる
    今どきのジュニアは、LLMの助けなしにコーディングした経験がほとんどないのではないかと思う

    • 昔、会社でデータ取り込み用モデルだけを何か月も作っていた時期があった
      あまりに退屈で出社するのもつらかったが、今ならLLMで数分で終わる気がする
      当時つぎ込んだ時間は、今思うとほとんど狂気じみている
    • Webデザインの最初の授業で、先生が一学期間ずっとNotepadだけでHTML、CSS、JSの**「基礎原理」**を教えていたのを覚えている
      その後でようやくDreamweaverが紹介され、生産性は10倍くらい上がった
    • LLMにおける**「職人気質 vs 実用性」**の緊張関係が興味深い
      セキュリティ研究のように結果が明確な分野ではLLMは優秀だが、微妙な判断が必要な問題には弱い
      だから反復的で体系的な部分はLLMに任せ、判断が必要な部分は人間が担うのが理想的だ
    • 20年以上プログラミングをしてきたが、LLMを使うことに見えない拒否感があった
      だが今では、これが**「新しいプログラミングのやり方」**なのだと受け入れており、そう認識するとむしろ若返ったような気分になった
    • 文中の「LLMの痕跡を見抜く人たち」という表現のすぐ後にem-dash(—) が出てきたのが面白かった
      最近はem-dashを使うとAIが書いた文章だと誤解されるのが少し腹立たしい

  • OxideのRFDを読んで大半にはうなずいたが、「LLMは最初からコードをうまく書ける」という部分には同意しない
    LLMは**「白紙恐怖症」**を解決するのには向いているが、実際にデプロイするコードはその出力物とはかなり隔たりがあると思う
    これは「進歩しているという錯覚」なのかもしれない

    • 文章は個人の表現だが、コードは問題解決のための道具だ
      LLMはデータセットに多く現れる**「良い解決策」を学習しているため、問題解決には強い
      一方で人間の表現は多様性が本質なので、平均的な表現は面白みを失う
      結局、LLMは未解決問題を解く能力を制限する可能性もある
      コード品質が低い理由は      context windowの限界**にあると見ている
    • ありきたりな文章は悪いが、ありきたりなコードはむしろ良い
    • 「別のモデルを使ってみろ」という反論は、もはやLLM界の**「No True Scotsman」**のように感じる
      関数単位の生成は悪くないが、機能全体を任せると構造やインターフェースがめちゃくちゃになる
      文章にたとえるなら、段落の最初の文と最後の文だけ与えて残りを埋めさせるくらいがちょうどいい
    • 自分たちがよく知る分野のニュースは誤りにすぐ気づくが、知らない分野だとそのまま信じてしまう現象に似ている
      プログラマーはコードの品質を判断できるが、文章についてはそうではない
    • LLMの品質はモデルによって異なる
      古いモデルや廉価なモデルを使って悪い印象を持っている場合が多い

  • 「LLMはLLMが書いた文章をうまく見分けられる」という主張には疑問がある
    データで示されているのか気になる

    • OxideのBryan自身が説明している
      同社の採用プロセスは文章重視であるため、最近はLLMで作成された応募書類が急増しているという
      RFD 0003と採用ページでも注意を促しているが、それでも発生し続けている
      ポッドキャストのエピソードでも関連事例が扱われている
      LLMがあらゆるAI文章を見抜けるわけではないが、疑わしいケースを検知する補助ツールとしては有用だという
    • LLMが作った文章を判別する方法として、テキストの半分をLLMに入れ、残り半分を予測させてn-トークン確率を比較するというアイデアが提案されていた
      実験はしていないが、興味深いアプローチだ
    • LLMがどの程度介入したか(全文作成、要約、校正など)によって検知の難しさが変わるため、
      現在の技術では完全な判別は不可能だと思う

  • LLMが書いたコードを使う際の責任はエンジニアにある
    自分でレビューしていないコードはレビュー対象にしてはならない
    私の手順は次の通りだ:

    1. 関連コードを入力 → 2) 目標を説明 → 3) 設計を検討 → 4) コードを生成 → 5) テストと修正 → 6) コード全体を精読し手動で修正
      最後の段階がいちばん難しく、感情的には飛ばしたくなる
      このやり方はアーキテクチャレベルの思考を保ちながら、反復作業を減らしてくれる
      ただしLLMは非決定的なので、コンパイラのように予測可能な道具とは異なる
    • 実際には6段階目が全時間の大半を占める
      コードが正しく動かなければ、さらに多くの修正が必要になる
      そのため、LLMが本当に時間を節約しているのか確信が持てない
    • 4段階目の前にテストコードを先に生成させ、いったん失敗させてから通す手順を加えるとよい
    • 手動修正の代わりにLLMにすべての変更を主導させれば、セッション内で知識の一貫性を保てる
    • こうするとエンジニアの自尊心と所有感が損なわれるように感じる
      機械が作ったコードを磨き上げる作業には、感情的に没入しにくい

  • LLMが生成したコードの著作権侵害の可能性に触れていないのは不思議だ
    GitHub上のコードがそのまま複製される可能性もあり、これはオープンソース企業にとって重要な問題だ

    • LLM生成物が著作権の対象でないなら、Copyleftライセンスのコードの法的地位が曖昧になる
      著作権が成立するには十分な人間の寄与が必要だが、その基準が不明確だ
    • こうした問題が法廷で扱われたことがあるのか気になる
    • 最新のLLMでもなおこうした問題が起きるのか、あるいは人間より頻繁に起きるのか疑問だ

  • 文書はよくできているが、「LLMを読解補助に使うのは問題ない」という部分は矛盾しているように感じる
    完璧なら原文と変わらないし、完璧でないなら誤読のリスクがある
    実際、LLMが文書をちゃんと読まず、目次だけ見て推論している場面をよく目にする
    コンテンツと読者の間に翻訳レイヤーが生まれる危険がある

    • RFDは「読むこと」ではなく「書くこと」に対する社会的期待の話だったのだと思う
    • 技術書3冊を比較させて誤った結果を出したなら、それはツールの使い方の失敗だ
      テキスト全体を直接context windowに入れるべきだ
      ただし3冊分まるごとではLLMの限界を超える分量かもしれない

  • 「LLMが書いた文章は思考の真正性まで損なう」という意見に共感する
    人間が直接書いた文章には価値があるが、LLMが書いた文章は価値が薄められた複製物のように感じる
    いっそプロンプトを読んだほうがましだ、という言葉が印象に残った

    • 人間の芸術は個人の内面を表現するが、LLMは集団平均の産物だ
      面白く独創的な発想は平均から外れた場所にある
      翻訳のように、非ネイティブ話者が自分の考えをよりよく表現するためにLLMを使うのは理解できるが、
      受け手はその表現が本当にその個人の考えなのか疑うようになる
    • Naurの"Programming as Theory Building"を思い出した
      コメントはコードに書かれていない理論的文脈を表現しようとする試みだ
      LLMはこのような「理論」を持ちえないため、本当に価値あるコメントは作れない
    • LLM特有の**「AIっぽい文体」**が嫌いだが、多くの人はそれに気づかない
      たとえば/r/SaaSの投稿の大半はLLMが書いたように見えたが、
      感情的なストーリーテリングによって読者の反応をうまく引き出していた
      私自身も文書やベンチマークの作成にはLLMを活用している
      非ネイティブ話者が技術文書を書く際にも役立つが、品質のばらつきは大きい
      結局、情報伝達のための文章ではLLMがますます有用になっている
    • 「プロンプトを読みたい」という感覚は、ニュースの見出しを見るときにもある
      何が書かれたかではなく、なぜそれが書かれたのかが知りたい
    • LLMは平均的な文を予測するのは得意だが、創造的な文はほとんど当てられない
      だから自分の考えが独創的でないとしても、統計的にはまれなのだと思うと少し慰められる

  • LLMで書かれた文章は読む価値がないと思う
    Oxideがコード以外の成果物にはLLMを使わないという断固たる原則を定めたのはよいことだ
    コードレビューでも同様に、生成コードはまず作成者自身が確認すべきだ
    こうした文化が本当に維持されるかは見守る必要があるが、方向性としては賢明だ

  • LLMは盗用されたデータで学習されたという認識が強く、
    そのような世間の認識を考慮すべきだったと思う
    倫理的問題であれブランドリスクであれ、今は明らかに重要な要素だ

    • この文書は一般向けではなく、社内技術文書として見るべきだ
      倫理的立場を示すよりも、技術的ガイドラインを提示することが目的だ
    • 文章中で述べられている「信頼の崩壊」が、まさにその問題を別の表現で扱っているように思える
      LLMが書いた文章は真正性を失い、読者はその思考までも自動化されたもののように感じる
      結局、相互の信頼を損なうことになりうる

  • 「書くことは読むことよりも大きな知的労働だ」という言葉は興味深い
    ただ、コードについては逆だと感じる

    • ひどい文章は役に立たないが、ひどいコードでもとりあえず動きさえすればJiraチケットを閉じられる
      だから粗悪なコードのほうがずっと多い
      一方で、よく書かれたコードには学ぶ価値が大きく、文章のように洞察が必要だ
    • Kernighanの法則が引用されていた
      「デバッグはコードを書くことの2倍難しい。
      したがって、書く時点で最大限に賢く振る舞うと、デバッグは不可能になる」
      laws-of-software.com リンク