  |
はてなキーワード:リポジトリとは
一連のShopify強奪事件によって、BundlerとGemsがrubycore teamに還元されたが、ついに管理権限の全権掌握に失敗した。
そもそもrubyとはrubyという言語単体の開発とメンテを司っており、言語仕様は見ているがエコシステム全域を見てるわけではない。Matzですらそうだ。
rubyにおいては、BundlerもGemsも言語の付属品という立ち位置だ。
近年の言語は言語仕様もパッケージ管理システムも全部コアメンテナに権限を委譲する。しかしrubyはそうなっていない、C/C++のように。
bunやrustに馴染んでる人には意味がわからないかもしれないが、往々にしてこんな権限統合失敗事案はOSSのアセットマネジメントにつきものだ。
古くはperlが、そしてその後phpもが、やらかした。web業界は過激なオープン思想の裏で、常に権限の落ち着きどころにリポジトリを悩ませている。
だから自由という名の管理放棄パッケージから、法人格での中央集中管理へとOSSはシフトしてきた。ここ１０年でFOSは死んだと言って良い。
ソースコードの開示はサプライチェーンの混入可能性を第三者検証可能にする健全性の証左としてきた。OSSコミッターの高額収入はこの信用性が担保していた。
しかし自由ソフトウェアとは自由の範囲を明示的に境界引きしており、本件では自由の範囲外にBundlerとGemsがあった。
つまり自由とは何であるか政治的に理解してない局面においてOSSコミッターはそれを行使するのに無力であり、実際法人格のプレッシャーに負けた事を証明した。
これは歴史的転換点だと思う。
Matzが間に入らなければ、rubyはメンテコストを捻出できず崩壊する所だった。たまたまMatzという優秀すぎる人間がいたので、どうにか死なずに済んだだけだ。
逆に言えばこの崩壊は真祖Matz以外が止められるものではなく実質、Shopifyの強圧に屈してrubyは死んだのだ。
金がないrubycore teamはShopify主導のサプライチェーン混入可能性を否定できない環境が整ったのだ。
日本だとクックパッドやSkebが該当するだろう。未だにruby製バックエンドを使ってる企業はサプライチェーン混入可能性を常に評価してrubyを運用する責務を負った。
どの言語だってその可能性は常に念頭にあるが、この歴史的転換点を観測してしまうと、高すぎるリスクを保有するテック企業として技術力を喧伝してきた信用は底値を叩く。
コンピューターサイエンスの信頼性という文脈で、信用を失うのだ。
一年が過ぎた。あの「何もしてないのに壊れた」事件の三人組は、今や職場のエースだ。
当時は「ディスプレイの電源の入れ方がわかりません」で全員の昼休みを潰した彼らが、だ。
人は成長する。いや、正確には「環境を与えられると覚醒する」というべきかもしれない。
あのあと、一応上司に報告した。「新人がディスプレイの電源を入れられない件について」と題したメールに、
あのときの顛末を淡々と書いた。報告を読んだ上司が言った一言が、すべてを変えた。
……え？
泣きたい。いや、もう笑うしかなかった。
Windowsのレジストリだのバッチファイルだのに全員アレルギーがあったらしい。
「Win端末って……Altキーが右にもあるの、何のためですか？」と真顔で聞かれたとき、
私の中の何かがそっと崩れた。
で、ちょうど一ヶ月後、上層部が「彼らの生産性を最大化するため」とか言い出して、
あっさりMac端末が支給された。MシリーズのMacStudio＋Studio Display構成。
「あ、それComposeで並列処理に変えました」とか平然と言う。
気づけばTerraformで開発環境をインフラ化までしていた。
処理速度？ 正確に計測したら、あのときのWindows仮想環境の十倍。
社内のGitリポジトリの更新履歴が、ほぼ彼らのコミットで埋まるようになった。
「それ、Homebrewで入れましょうか？」
……もう、何言ってるのか半分もわからん。
かつて「ディスプレイの電源が入れられない」と言っていた口で、
ただ、あのときの端末が彼らの性能に追いついてなかっただけ。
今日も彼らの後ろ姿を見ながら、私は小さく笑う。
——何もしてないのに、すごくなったな。
その「日本企業1990社を18年間追跡した研究」という主張について、私が確認できた限りでは、そのままの形で信頼性のある学術研究として裏付けられたものは見つかりません。いくつか類似・関連する研究はありますが、主張の文言（1990社・18年間・利益率低下）をそのまま支持するものは確認できなかった、というのが現状です。
調べた内容
Web記事などで、「日本企業1990社を対象に18年間の分析で、女性取締役が増えるとROAが0.1ポイント低下した」という記述が見られます。
→ ただし、その記事（ナゾロジー等）は学術論文ではなく、二次情報を噛み砕いて紹介したものです。
ナゾロジー記事自体では、「この研究は … 『Journal of Risk and Financial Management』に発表されている」といった表記があります。
→ ただし、その論文そのものを確認できるソースは私が見つけられませんでした。
日本の女性役員・取締役比率と企業業績の関係を扱った先行研究はいくつかあります。例として：
「上場企業における女性活用状況と企業業績との関係」では、正社員女性比率が高いほど利益率が高くなる傾向があるという結果が報告されています。
「女性取締役会構成と企業パフォーマンス」に関する研究では、日本企業においても、正女性比率と業績との相関が産業、企業規模、コントロール変数の扱いなどで変わるという指摘があります。
また、女性取締役比率と業績の関係については、正確な因果性を識別するのが難しいという指摘が多く、肯定的・否定的・中立的な結果が混在しているという整理もなされています。
Koara
先行研究のレビューをまとめた文献も、「女性取締役比率と企業パフォーマンス（ROA,ROE など）」の関係が、業種、企業のコントロール変数、内生性の扱い、サンプル期間・地域性などに強く依存するという見解を示しています。
主張の形（1990社、18年、利益率低下）をそのまま採るには、以下の点が問題です：
現時点で、その研究が査読を経た学術論文として公表されているという確証を得られていません。
一般に、女性取締役の増加が業績を一様に下げるという結論は、既存の日本・国際研究との整合性が取れないことが多い。様々な研究で、正負・中立の結果が報告されており、単純な「増えると下がる」という因果を支持するものは弱いです。
もしそのような相関があるとしても、「女性取締役が増えたから利益率が下がった」のか、「利益率が悪化していて、それが背景にあって取締役改編が行われた」のか、逆因果の可能性や操作変数をどう扱うかなどがクリアでないと主張は弱くなります。
以下では、提示された文章に含まれる主張を ①公的情報などで裏付けがとれる「ファクト」 と ②筆者の感想・価値判断・推測 に分けて整理しました。
（※「ファクト」に分類したものでも *正誤* ではなく “確認可能な事実を含む” という意味です。逆に「感想等」に入れたものは、裏付けが取れないか価値判断を伴う部分です）
| # | 該当箇所（要約） | 確認根拠 |
|---|---|---|
| 1 | チームみらいは2025年7月参院選で比例区1議席を獲得し、得票率2％超で政党要件を満たした | 朝日新聞・毎日新聞などの選挙結果報道 ([朝日新聞][1], [毎日新聞][2], [TOKYO MX][3]) |
| 2 | 設立は2025年5月、党首はAIエンジニア安野貴博氏 | 同上選挙報道・公式サイトプロフィール ([朝日新聞][1], [TOKYO MX][3]) |
| 3 | 公約（マニフェスト）はGitHubリポジトリや独自サイトで公開し、Pull Requestで修正提案を受け付けている | GitHub `team-mirai/policy`リポジトリ ([GitHub][4], [GitHub][5]) |
| 4 | キャッチフレーズに「だれ一人取り残さない（包摂）」を掲げている | マニフェスト ver.1.0 ([policy.team-mir.ai][6]) |
| 5 | 堀江貴文（ホリエモン）氏がYouTube対談で応援姿勢を示し、ReHacQチャンネルでも幹事長らが出演している | YouTube動画 ([YouTube][7], [YouTube][8]) |
| 6 | 「はてなブックマーク」でチームみらい関連記事が一定数話題になっている（記事ランキング等で確認可能だが「多いか少ないか」は主観） | B!Kuma総合人気記事欄などで計測可（ただし数量評価は要統計） |
| 7 | （GitHub閉鎖疑惑）2024都知事選後に一時的にアーカイブ化→現在は再公開 | 技術チームによる経緯説明note ([note（ノート）][9]) |
---
| # | 主張の骨子 | 性質 |
|---|---|---|
| A | 「はてなーに支持者が多いので、世間は政策で投票していない」 | 個人的推測（母集団調査なし） |
| B | 「石丸との差は“雰囲気”だけ／お気持ち支持」 | 評価・印象論 |
| C | 「ポピュリズムど真ん中の危うい人たちが取り巻き」 | レッテル貼りを含む価値判断 |
| D | 「政策を持たない（議論しない）ことと包摂方針は矛盾」 | 論理的批判だが前提（政策ゼロ）が事実と異なる可能性 |
| E | 「熟議なき多数決は民主政の正統性と矛盾」 | 政治理論に基づく意見 |
| F | 「参政党より危険」 | 相対的評価／危険の基準は示されず |
| G | 「オードリー・タンは人権中心だが、チームみらいには担保がない」 | 懸念表明（保証要件の有無は定義次第） |
| H | 「少議席を隠れ蓑に党勢拡大しようとしていて気持ち悪い」 | 感情的評価 |
| I | 「GitHubを閉じて説明がない＝白紙委任」 | 事実誤認の疑い／開閉の経緯説明が公開されている |
| J | 「AI関連以外の法案賛否の決め方が不透明」 | 問題提起だが現時点では検証困難 |
| K | 「批判を『いじめ』と称してスルー＝民主主義を舐めている」 | 個別言動の一般化・価値判断 |
---
castingccastingccastingccastingc
HTML（HyperText Markup Language）は、ウェブ開発における基本的な言語であり、GitHub上でも非常に重要な役割を果たしています。特に、ユーザーインターフェース（UI）を伴うプロジェクトでは、HTMLはウェブページの構造を作成するために不可欠です。GitHubでは、GitHubPagesという機能を使って、リポジトリから静的ウェブサイトをホスティングすることができ、HTMLはその基盤となります。
また、Markdownで書かれたREADMEファイルの中にもHTMLの要素を挿入することで、より視覚的で分かりやすいドキュメントを作成することができます。これにより、プロジェクトの情報を分かりやすく伝えることが可能になります。
オープンソースプロジェクトのコラボレーションにおいても、HTMLは開発の成果を他の開発者と共有したり、レビューやバグ報告をしやすくしたりするための大切な手段です。また、プロジェクトの構造を視覚的に理解しやすくすることで、他の人が貢献しやすくなります。
要するに、HTMLはGitHubにおいてコードとプレゼンテーションをつなぐ橋渡しのような存在であり、プロジェクトの可視化と共同作業において欠かせないツールです。
WSL2USBカメラ+他のUSB機器2022年09月06日版
WSL2LinuxKernel 5.10.60.1からKernelモジュールにUSBIP対応が標準的に組み込まれたらしいが、Microsoft公式が提供しているKernelや手順ををそのまま使用すると動作しない
2022年09月06日時点の最新カーネルは 5.15.62.1 だが、wsl --update で展開されるバージョンが 5.10.102.1 だったため 5.10.102.1 を使用する
以下すべての手順のWindows Terminal を使用する箇所は管理者権限 で実行
以下、[WT] はWindows Terminal、[Ubuntu] はUbuntu側のbashを表す
WSLのカーネルアップデートとusbipd-win のインストール
> wsl --update
> wsl --status
>winget install --interactive --exact dorssel.usbipd-win
見つかりましたusbipd-win [dorssel.usbipd-win]バージョン 2.3.0
Microsoft はサードパーティのパッケージに対して責任を負わず、ライセンスも付与しません。
Downloadinghttps://github.com/dorssel/usbipd-win/releases/download/v2.3.0/usbipd-win_2.3.0.msi
██████████████████████████████10.4MB /10.4MB
> wsl --install --distributionUbuntu-20.04
[WT] WSLのディストリビューションを起動（WSL2起動用アイコンをマウスでクリックして起動してもよい）
> wsl --list
Linux 用Windows サブシステムディストリビューション:
sudoapt install -ylinux-tools-5.4.0-77-generic hwdata
sudo update-alternatives --install /usr/local/bin/usbipusbip /usr/lib/linux-tools/5.4.0-77-generic/usbip20
> wsl --shutdown
[WT]USBカメラがusbipd に認識されることを確認する (この記事では 2-7)
2-2 056e:00d9USB入力デバイス Not attached
2-3 1c4f:0027USB入力デバイス Not attached
2-7 1bcf:2284 FullHDwebcam,USBmicrophone Not attached
2-11 0495:3011ESSUSBDAC,USB入力デバイス Not attached
2-14 8087:0029インテル(R)ワイヤレスBluetooth(R) Not attached
[WT]USBカメラをUbuntu側にアタッチする（アタッチに成功した場合は何も表示されない）
>usbipd wsl attach --busid 2-7
>
[WT]USBカメラが正常にアタッチされていることを確認する（Attached と表示されていれば成功）
2-2 056e:00d9USB入力デバイス Not attached
2-3 1c4f:0027USB入力デバイス Not attached
2-7 1bcf:2284 FullHDwebcam,USBmicrophone Attached -Ubuntu-20.04
2-11 0495:3011ESSUSBDAC,USB入力デバイス Not attached
2-14 8087:0029インテル(R)ワイヤレスBluetooth(R) Not attached
[Ubuntu]Ubuntuのbashにログオンした既定のユーザを videoグループに所属させる。なお、WSLを起動した時点で既に追加されているメッセージが表示される。
[Ubuntu] WSL2上のUbuntu20.04 の中からUSBカメラが認識されていることを確認する。lsusbコマンドを経由すると正常にUSBカメラが認識されているが、/dev/video* にはUSBカメラが列挙されない
Bus 002 Device 001:ID 1d6b:0003Linux Foundation 3.0roothub
Bus 001 Device 003:ID 1bcf:2284Sunplus Innovation Technology Inc. FullHDwebcam
Bus 001 Device 001:ID 1d6b:0002Linux Foundation2.0roothub
ls: cannotaccess '/dev/video*': No such file or directory
[Ubuntu]USB CameraがWSL内で認識されるようにLinuxカーネルをカスタムビルドする。下記リポジトリの手順通りに実施すると、WSLLinuxカーネルがカスタムビルドされたものに入れ替わる。注意点は、<windowsusername> の部分だけは各自の環境のWindowsユーザー名に手で書き換える必要が有ること。なお、.wslconfig は絶対にwindows 側で編集してはならない。絶対に。
> wsl --shutdown
[WT]USBカメラがusbipd に認識されることを確認する (この記事では 2-7)
2-2 056e:00d9USB入力デバイス Not attached
2-3 1c4f:0027USB入力デバイス Not attached
2-7 1bcf:2284 FullHDwebcam,USBmicrophone Not attached
2-11 0495:3011ESSUSBDAC,USB入力デバイス Not attached
2-14 8087:0029インテル(R)ワイヤレスBluetooth(R) Not attached
[WT]USBカメラをUbuntu側にアタッチする（アタッチに成功した場合は何も表示されない）
>usbipd wsl attach --busid 2-7
>
https://www.imdb.com/de/list/ls599665017/
https://www.imdb.com/de/list/ls599665017/copy/
[WT]USBカメラが正常にアタッチされていることを確認する（Attached と表示されていれば成功）
2-2 056e:00d9USB入力デバイス Not attached
2-3 1c4f:0027USB入力デバイス Not attached
2-7 1bcf:2284 FullHDwebcam,USBmicrophone Attached -Ubuntu-20.04
2-11 0495:3011ESSUSBDAC,USB入力デバイス Not attached
2-14 8087:0029インテル(R)ワイヤレスBluetooth(R) Not attached
[Ubuntu] WSL2上のUbuntu20.04 の中からUSBカメラが認識されていることを確認する
Bus 002 Device 001:ID 1d6b:0003Linux Foundation 3.0roothub
Bus 001 Device 003:ID 1bcf:2284Sunplus Innovation Technology Inc. FullHDwebcam
Bus 001 Device 001:ID 1d6b:0002Linux Foundation2.0roothub
crw------- 1rootroot 81, 0 Sep 617:29 /dev/video0
crw------- 1rootroot 81, 1 Sep 617:29 /dev/video1
[Ubuntu]USBカメラがWSL2の中から認識されることを確認するテストコードを作成する
$ pip installopencv-contrib-python
$ cat << 'EOT'> ${HOME}/usbcam_test.py
import cv2
W=640
H=480
cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc('M','J','P','G'))
#cap.set(cv2.CAP_PROP_FOURCC, cv2.VideoWriter_fourcc('Y','U','Y','V'))
cap.set(cv2.CAP_PROP_FRAME_WIDTH, W)
cap.set(cv2.CAP_PROP_FRAME_HEIGHT, H)
https://www.imdb.com/de/list/ls599660855/
https://www.imdb.com/de/list/ls599660855/copy/
whileTrue:
ret, frame
Custom CVATリポジトリ
修正した箇所は２箇所のみ
django の起動時ヘルスチェックのうち、ストレージ空き容量に関するチェック部分の10 (10%の意味) を None に書き換える。なお、私のカスタムCVATのリポジトリにコミットされているリソースはすでに修正を反映済みのため、下記の修正を加える必要はない。
3-3. 該当のissue
CVAT fails health check using>90% disk #5449
3-4. Custom CVAT の実行手順
下記を順番に実行するだけ。
git clonehttps://github.com/PINTO0309/cvat_custom.git
cd cvat_custom
https://ngarangansawah.graphy.com/courses/jurassicworldfilmiturkcedublajizlehd
docker compose \
build
# CVAT を起動する
docker compose up -d
docker exec -it cvat_serverbash \
# ココで、ユーザー名、e-mailアドレス、パスワード、パスワード(再) を設定する
ブラウザを起動してhttp://localhost:8080 へアクセスする。下図のようなログイン画面が表示されれば成功。
https://ngarangansawah.graphy.com/courses/jurassicworldyenidengogusizlefilmihd
ログイン後のトップポータル。ここに Projects なり Tasks なりを追加してローカルだけで全ての作業を完結することができる。
下記の通り、公式のチュートリアルどおりにdocker compose あるいはdocker-compose を使用して CVAT を起動すると問題を再現することができる。
cvat を clone してdocker compose あるいはdocker-compose を使用して必要なリソースを全て起動する。
git clonehttps://github.com/opencv/cvat.git
cd cvat
git checkout bf4089ead320d8f6a80e0a1793c8406ec46daee8
docker compose up -d
https://xemjujutsukaisen.graphy.com/courses/xemphimjujutsukaisenvietsubfullhd
ブラウザを起動してhttp://localhost:8080 へアクセスする。
30秒後、突然エラーが表示され、ログイン画面が表示されるはずのタイミングで下記のエラーがダイアログでポップアップしてきてCVATにアクセスできない。なお、表示されるエラーメッセージは無意味なものであり、ログイン画面にアクセスできない原因を一切示唆していない。
エラーメッセージ
Cannotconnect to the server
Make sure the CVAT backendand all necessary services
(Database,Redis andOpen Policy Agent) are runningand available.
Ifyou upgraded fromversion 2.2.0 or earlier,
manual actionsmay be needed, see the Upgrade Guide.
https://xemjujutsukaisen.graphy.com/courses/xemphiminventoryprematuredetahfull
3.ストレージ不足問題を突破してCVATをローカルで実行する方法
以下のとおりの手順でCVATを起動する。私が本家のCVATリポジトリをForkしてストレージ制限を解除したカスタムCVATを作成してGitHubへコミット済みのものを使用する。
https://anond.hatelabo.jp/20250630114221 https://anond.hatelabo.jp/20250626125317 https://anond.hatelabo.jp/20250627100609 https://anond.hatelabo.jp/20250628122821
AI技術を批判する記事がバズりまくってるが、それに対して凄い数の批判がいってる、だけど肝心の批判は個人攻撃めいていて、どれも技術的な部分はふわふわした物言いなので
どれだけ技術的にまったく使い物にならないかを、技術面から3つ理由を上げようと思う、これを見れば、確かにＡＩってそんなもんじゃないな、って正しい理解が進むと思う、と同時に、
ネットでAIを擁護したり喧伝してる人間で誰一人、エンジニアを自称したりしてる奴らでさえAIを理解してる人間がゼロっていうのがわかると思う
ちなみに、IT技術を全然知らない増田向けに技術的な部分は補足説明を入れているので、ちょっと長くなってるかもしれない
LLMがわかっていない！と喚いてる当人たちも上で言った通り、LLMっていうのが理解できてないの丸わかりなので、ここでまずLLM「大規模言語モデル」とは何かを簡単に説明しよう
生成AI（特にChatGPTのような大規模言語モデル、LLM）というのは「文脈に最もふさわしい次の単語を予測する」」という統計的タスクを行っている、これがLLMだ
「飲みます」→90%の確率 「買いました」→7% 「投げました」→0.5%
この過程には、意味理解や感情、意図、文脈の内的把握は一切関わっていない、これが致命的な欠陥の1つ
プログラミングを自動でまるで仮面ライダー01の01ドライバーの様にベルトの作成までやってくれているように喧伝してる奴らが多い
が、これを本気で信じ込んでプログラミング言語を書かせた奴がいたら、ほぼ間違いなくクビになる
わかりやすく上で例えた通り、LLMは、インターネット上に存在する膨大なコード断片・技術記事・GitHubリポジトリ・StackOverflowの投稿などを学習している。
そのため【よく使われる文法構造】や【特定の言語における関数の使い方】や【ライブラリの典型的な使い方】などを【意味を全く理解できず模倣している】だけって事
【動かないコードをアホほど入れる(変数が未定義、型が合っていない、ライブラリに存在しない関数を呼んでいるとかいう小学生のプログラミングスクールでもありえないミス】
【. 「それっぽいけど間違っている」コードを大量に入れ込む(SQLインジェクション、XSSなどセキュリティ上危険な実装を入れまくる、パフォーマンスが極端に悪い実装、バグを含んでいるロジック（特にif文の条件分岐ではほぼ100％発生する)】
【実行環境に依存した誤り(存在しないAPIやライブラリを使う、ほぼ9割の確率で…あと特定のPythonバージョンやNode.js環境でしか動かないコードを汎用的に提示、つまり動きようがない)
専門的な意見となったのでわかりづらいので、もっとわかりやすく言うと「小学校のプログラミングスクール入りたて1週間の子供が書いためっちゃくちゃなプログラミングにすらなってないコードを、製品利用するからレビューして出してこい」と言われてるに等しい、つまり、最初から自分で書いた方が早い2度手間になる
これが、プログラミングの革命だ！とか喚いてる奴らが隠すAIの実態である。
import jwt
token = jwt.encode({'user_id': 123}, 'secret', algorithm='HS256')
一見正しく見えるだろうから解説すると、実際には 【jwt という名前のライブラリ】が複数存在し（PyJWT,python-jwtとか）importの仕方によってエラーが出たり挙動が変わったりする。普通なら絶対間違えない様な挙動をAIは構造上全く判断できない、これは上で上げた根本的な問題なので恐らく絶対に解決できない。
ハルシネーションがどういうものであるのか、AI批判でバズった記事などで言及されている通り、デマやデタラメを出力してしまう、あれは本当にわかりやすいAIの致命的欠陥を検証してるので、あえて説明はここではしない。
しかもその増田の元記事では「文章データのテキストまで読み込ませれば間違いがなくなるのでは？」といってたが、これも絶対になくならない、というより、もっとひどくなる。
批判をしている増田やXでの意見は単なる個人攻撃の誹謗中傷のみで、技術的に改善可能なプロセスさえ示せていない、例えば現在研究者の間では以下の様な解決案は研究されているが、どれも全く問題外とされている
これは、AIが「知っている風」に語る代わりに、外部の信頼できるデータベースや検索エンジンから情報を引っ張ってくる方式、バズった元記事の増田がやっていた「自分で図書館言って本の内容読んで誤りであることを確認する」これを検索エンジン使ってAIにさらにやらせる、という機能だ
また【メタモデル】すなわち、AIが自分の出力を裏でさらに別のAIが別プロセスでチェックして間違いをただす、という方式も研究されてる。
これは致命的な欠点が2つある、まず「検索で引っ張ってくる知識そのものが間違いだった場合、さらに間違いの結果を出し続ける」ということ。
元記事の増田はMP5というマシンガンの有効射程について突っ込んでいたと思うが、これが典型的なRAG、メタモデルの致命的欠点、元増田は「実際に自分の手で銃を取り扱ったりしたことがある確かな経験で言ってる」が、書籍などの工業スペックや仕様書の定義でしかネット上では流布してない、だからそもそも答えというものにAIがたどり着けない。
2つ目は「文脈や倫理・常識・道徳が根本的に読めないので、解決策が乱暴すぎるもの」になる。
上で上げた鉄砲以外では、例えば医学などでこれをやってしまうと取り返しのつかないことになる。例えば医者の投薬治療や治療はガイドラインに従ってるというが、優れた医者は論文を読み込んで原理は不明だがエビデンスはあるので、漢方薬を出したりするというお医者さんがよくいるだろう。あれは実際に患者を診て、西洋医学的には全く問題ないが、心理的な面も絡んで心身症になっているから、論文などで勉強して「暗黙知、経験知」として処方してるし、その量も患者を診た医者の経験で精度を上げている。
そして医療分野では、「冷え性の軽いむくみ」に対して「サムスカ（トルバプタン）」という劇薬指定の危険な利尿薬をAIが提示した事例すらある。これを「笑い話」で済ませることはできない。
例えるなら判断が「脳外科医竹田君」並になる、投薬治療で3か月で治る程度の病気を、病根から外科手術で切除しましょう、なんて提案になる。最新のAIなのに80年前みたいな医学知識と判断になってしまうのだ(胃潰瘍ってだけで胃袋は全摘、ついでに脾臓と盲腸もいらねーからとっとこ、みたいな手術が昭和の昔、本当にガイドライン治療だった、「K2」などで言及されている)
学習できるベースがどうしても偏る以上、情報の統合に限界がある、さらに間違いが間違いをよび、さらに変な間違いを起こしたりありえない架空のことをいったりする、これがハルシネーションというメビウスの輪である
Neuro-symbolicAIという次世代のさらに文脈も読み取れるアーキテクチャAIを研究しているが、全く実用化されていない、核融合や量子コンピューターみたいな雲をつかむ話なので、AIがこの問題を解決することは恐らく今後数百年はありえない、という結論が出ている。
元増田の記事で批判もあったが、恐らくAIで一番致命的な問題はこれ
基本的にAIは英語ソース、つまりリングワ・フランカで圧倒的にテキスト量の多い(約95％)英語、日本語含めそれ以外の全世界言語が5パーセントという偏った学習になっている
そのため、倫理・道徳・常識・規範などがすべて西洋基準になってしまう、という問題がある。(元増田はこれを「脱獄の基準の倫理は誰が決めるのか？」と根本的な問題に気が付いていて批判していたようだ)
ちなみに、バズってた例の記事に「AIに書かせたんだろ」という批判も大量にあるしよくみかけるが、この場合においてのみ言うなら、これは③の問題からまずありえないということがわかる、以下が根拠だ
元増田は「俺達の麻生とかいって秋葉原で踊ってた…」とか「レムちゃん、エミリアたん、ヘスティアちゃん、ウマ娘たん、刀剣乱舞くん、ライカン様…」といった批判を繰り返し書いていた
これに激怒できる人間は、2005～2010年にオタク界隈や秋葉原にすでにかかわっていて、実際に渦中にいたか同じ属性の人間でしか、罵倒されていると文脈的に理解できないのである。つまり、大量の英語文化圏情報を食ってるAIではなんでそれが罵声や侮蔑なのか理解できないので、書きようがない表現の数々、であるということである。
AIからすれば「ライカン様？ウマ娘？なんじゃそりゃ」なのである、もっと言えば、その直後にコンテクストとして「アホ、ボケ、弱者男性、豚丼、性器や自慰で虚しく…」といった言葉があるから、なんならAIはウマ娘やライカンをキャラクターでなく侮蔑単語として理解してしまう、これは実際、元増田の記事の一文をAIに食わせて質問したらガチでそうなるので、ぜひお手元で試してもらいたい。
「プログラマーのイメージを描いて」と依頼すると、男性の画像ばかりが出るされる
「看護師」→女性、「エンジニア」→男性という職業的性差が自動的に反映される
「アフリカの文化」→貧困・紛争・サバンナなど、植民地主義的視点が強く反映される(実際は南アなどはすげえ都会である)
これに前述のハルシネーション問題として現れれば、人間と同じような差別や偏見を「ガチの真実」として学習してしまう、人間の場合、8割くらいは本当はおかしいこととメタ批判が心理的にできるとされているが、AIにはその構造が根本的に存在しない。
元増田の記事のコメント欄やXなどで元増田のAI批判を批判しつつ、「金持ちの上級白人専用のハイエンドAIがあるに違いないんだ」といっている意見が少なくない数がある。
冷静に考えれば、そんなめんどうくせえもん誰が作るんだ、と普通に考えればわかるのだが、この③の問題、すなわち95％の学習データが英語ソースなので、結果的に西洋文明ベースの文化圏の人間向けにカスタマイズされているので、アジア圏やその他文化圏では利用に不利でそう感じてしまう素地ができている、という錯覚に由来している
例えば、パレスチナ問題などがそうだ、ガザ地区でほぼ国際条約や人道違反の残虐行為を国が行っているわけで、他文化圏や歴史的文脈から見ればどっちかって言えばパレスチナ人こそ被害者なのだが、イスラエルから見ればそれは正義であり正当な攻撃なわけで、後者の方がＡＩは正しいと判断した結論を下す様になる、といった問題である
あの記事の元増田は「テロ組織のヤバイマニュアルまで学習してpdfで元データを提示してきた」と言っていた。実際AIに調べさせて持ってこさせてみると、出所はアメリカの法務執行機関が研究用にネットで公開したものであった。
日本人や日本の警察の対応レベルで「ヤバイ」ものでも、海外の軍隊みたいな装備の警察で見れば大したことがないから、公開させてもいい＝倫理違反には当たらない、という文化規範の意識の違いを、あの元増田自身が証明してしまっている、あの記事は、ＡＩの治しようがない根本的な技術的欠陥をほとんど言及しているといっていい
元増田が口汚く罵っている内容の様に、「AIは0を1にできないから格差が広がるだけ」という根本的な哲学を投げつけている
それを受けて批判してる意見の中には「(自分が1を持ってる側と何故か根拠もなく信じ込んでて)100にできるから(なら)便利」とか「そのAI今から勉強したりしてる俺たちは先行者利益で強者になれる」と信じて疑わない意見が多かった
③問題の通り、そもそも非キリスト教圏かつ非英語圏の国家で生まれて育った民族、というだけで、我々は等しく「０」側の人間であり、結局競争になると勝てない、ということに全く気が付いていないのである。ここにAI信者の宿痾といえる病理がある
かつて日本人は黒船を見て5年そこらで蒸気機関を模倣した、火縄銃を一丁買えば10年でオスマン帝国の次に鉄砲を使うようになった、それは当時の日本人の基礎工学技術が導入可能なほど優れており、かつそれに対して現代では考えられないほぼバクチといっていい投資を行った結果であって、その結果を見て自分たちはAIを使いこなせて強くなれるなんていうのは、物凄い妄想である。つまり、AIは少なくとも「非英語圏」の人間にとっては、ブレイクスルーは絶対に起こりえない、ということである。
Permalink |記事への反応(17) | 08:43
Twitterの「the-algorithm」リポジトリをもとに、推薦アルゴリズムを数学的に極限まで抽象化すると、以下のように表現できます。
ユーザー u ∈ U に対して、一連の候補アイテム（ツイート） i ∈ I をスコア付けし、降順に並べて上位 K を表示します。
要するに、以下を最大化する推薦問題です：
argmax{i∈C(u)} S(u,i)
ここで C(u) は候補集合、S(u, i) はスコア関数。
数千万から億単位のツイート全体 Iから、まず候補集合 C(u) ⊂ I を生成。
グラフ構造（フォロー関係）や「SimClusters」「TwHIN」など埋め込みから近似。
検索インデックス（Lucene/Earlybird）による検索スコアによる絞り込み 。
数理的には、潜在空間中でユーザーとアイテムの距離または類似度sim(u, i) が上位のものを選ぶ操作。
候補数をさらに削減。特徴量 xᵤ,ᵢ を簡易学習モデル（線形モデルなど）に入力し出力スコア：
Slight(u,i) = wᵀxᵤ,ᵢ
多層ニューラルネット＋マルチタスク学習で、複数のユーザー行動（いいね、リプライ、リツイートなど）確率 Pₖ(u, i) を予測。
S(u,i) = Σₖ αₖPₖ(u,i)
例：リプライ Pᵣₑₚₗᵧ に重み 27、著者返信あり Pᵣₑₚₗᵧ_ₐᵤₜₕₒᵣ に 75 など。
投稿者がBlue Verifiedなどでスコアを×4または×2倍。
同一投稿者続出の抑制、逆風バイアス（negativefeedback）などが入る。
これは以下のような修正：
S̃(u,i) =mS(u,i)
この構成は一般的なレコメンダシステムの「Retrieval → Ranking → Filtering」の標準パイプラインと整合。
学習モデル fᶿ は特徴量集合・ニューラル構造・訓練データによって依存し、ブラックボックス的。
特徴量 xᵤ,ᵢ は埋め込み、行動履歴、文脈、信頼性指標（tweepcred）等多次元で複雑。
スコア重み αₖ は明示されるが、最適化は A/Bテスト・実システムでの評価に基づく。
信頼性・安全性のルール はフィルタとして明示されるが、その詳細（具体的しきい値など）は省略・秘匿されている。
S̃(u,i) = m(u,i) Σₖ αₖ fᶿₖ(u,i)
ここで、
という、レコメンドパイプラインの抽象テンプレートに帰着します。
Twitterの「the-algorithm」は、コード構造の多くを公開しているものの、モデルパラメータ・学習データ・設定ファイルは秘匿されており、上述パイプラインの数学的な枠組みは把握できても、実際の挙動はまだブラックボックスです。
とはいえ、レコメンデーション理論の観点からは、上記の抽象モデルで十分に説明可能であり、汎用の数学モデルとして整合しています。
何もしないと個人リポジトリ―のコードが取り込まれ、設定によってはどんなライセンスのコードだろうと取り込まれることだ。たとえば…
https://github.com/timdetering/Wintellect.PowerCollections/blob/master/Binaries/License.txt
Commercial distributors ofsoftwaremayaccept certain responsibilities withrespect to end users, business partners andthe like. While this licenseis intended to facilitate the commercial use of the Program, the Contributorwho includes the Program in a commercial product offering should do so in a manner whichdoes not create potential liability for other Contributors. Therefore, if a Contributor includes the Program in a commercial product offering, such Contributor ("Commercial Contributor") hereby agrees to defend and indemnify every other Contributor ("Indemnified Contributor") againstany losses,damages and costs (collectively "Losses") arising from claims,lawsuits and other legalactions broughtby a third party against the Indemnified Contributor tothe extent causedby the acts or omissions of such Commercial Contributor in connection withits distribution of the Program in a commercial product offering. The obligations in this section do not apply toany claims or Losses relating toany actual orallegedintellectual property infringement. In order to qualify, an Indemnified Contributor must: a) promptly notify the Commercial Contributor in writing of such claim, and b)allow the Commercial Contributor to control, and cooperatewith the Commercial Contributor in, the defenseand any relatedsettlement negotiations. The Indemnified Contributormay participate inany such claimatits own expense.
For example, a Contributor might include the Program in a commercial product offering, Product X. That Contributoris then a Commercial Contributor. If that Commercial Contributor then makes performance claims, or offers warranties related to Product X, those performance claims and warranties are such Commercial Contributor's responsibilityalone. Under this section, the Commercial Contributor would have to defend claims against the other Contributors related to those performance claims and warranties, and if a court requiresany other Contributor to payanydamagesas a result, the Commercial Contributor must pay thosedamages.
5. NO WARRANTY
EXCEPTASEXPRESSLYSETFORTH IN THISAGREEMENT, THE PROGRAMIS PROVIDEDON AN "ASIS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OFANY KIND, EITHEREXPRESS OR IMPLIED INCLUDING, WITHOUT LIMITATION,ANY WARRANTIES OR CONDITIONS OFTITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipientis solely responsible for determining the appropriateness of using and distributing the Programand assumesall risksassociated withits exercise of rights under thisAgreement , including but not limited to the risks and costs of program errors,compliance with applicablelaws,damage to or loss of data, programs or equipment, and unavailability or interruption of operations.
ThisAgreementis governedby thelaws of theState ofNew York and theintellectual propertylaws ofthe UnitedStates of America. No party to thisAgreementwill bring a legalaction under thisAgreementmore thanone year after the cause ofaction arose. Each party waivesits rights to ajurytrial inany resulting litigation.
アメリカのニューヨーク州なので、ニューヨーク州法と連邦法が適用される。
もし、Github codepilotでBigListやNode、Bagなどのコードが出てきたら、注意したほうがいいぞ。
https://www.ai-souken.com/article/github-copilot-copyright-issues
訴えている奴がマジでいるんで、CodePilot Businessのほうは公開されているコードは取り込まないという設定を有効にしておいたほうがいいと思われる。
中学校在学中にプログラミング言語を開発し経済産業大臣賞（総合）を受賞した上原直人氏という方がいます。
上原直人氏が開発した「Blawn（ブラウン）」の使い方を調べてみました。
Blawnには後継のClawn（読みはクロー？クラウン？）が登場していました。
こちらがClawnです。
https://github.com/Naotonosato/Clawn
Clawnはgithubにあります。リポジトリをcloneする必要があるそうです。
https://www.kagoya.jp/howto/it-glossary/develop/howtousegithub/
https://qiita.com/sh10n/items/f5edb7293aaffebe35a7
https://github.com/Naotonosato/Clawn
次に下記、これは前のBlawnを使った例です。おそらく参考になるかと思います。多分ですが。
ウワサのBlawnを触ってみた
https://qiita.com/blackenedgold/items/83526b329fe96ee781f5
私自身Clawnがまだ使えていません。初心者向け言語のはずですが現時点では環境構築のハードルが初心者向けとは言い難いので、githubの使い方に慣れている方以外はじっくり調べながら・・・となるかと思います。
IT業界ではよくある話だが、「プロ中のプロ」「即戦力間違いなし」みたいな触れ込みでやってきたメンバーがいた。営業が何を言ったのか知らないが、やたらと期待値高めで参画してきたので、とりあえず大枠の指示だけ渡して、あとはお任せという形にした。
任せた作業は、普通ならベテランなら4、5日で終わる程度。決して簡単ではないが、経験豊富な人間ならそれほど苦戦するようなものではない。正直、自分たちでも一から調べてやればできなくはないが、他の仕事との兼ね合いがつかなくてアウトソーシングすることになったという話だ。
ところが、1ヶ月経っても作業は進まず。原因を聞けば「アカウントの問題で止まっている」とのこと。それなら仕方ないかと、しばらく静観していた。特に急ぎでもなかったし、どうせプロなんだからそのうち解決するだろうと楽観していた。
だが、2ヶ月目に突入しても状況は変わらず。報告内容も「サポートに問い合わせ中」「管理者に連絡中」など、他責のオンパレード。こちらとしては、そろそろ納期も見えてきたし、悠長に構えていられない。
目を疑った。
そこには、まさかのパスワードがベタ書きされたコードがコミットされていた。しかも、修正の痕跡もなく、そのまま堂々とプッシュされていた。
正直、言葉を失った。
「プロ」と名乗る人間が、こんな基本的な初歩的なセキュリティすら無視するとは。
gitignoreの使い方もわかってない。コード管理の概念すら怪しい。
「これは成長の余地がある」とか「方向性を見誤っただけ」とか、そんな擁護すら思いつかないレベル。もはや何を信じて任せていたのか、自分を問い詰めたくなった。
ChromeOSやAndroidOSへ提供されるLinux環境は元増田の通りDebianなので普通にAPTが使えてDebianのリポジトリからパッケージが提供されるから仮想環境の上に仮想環境載せるとかルーティングが複雑になるような事をしなければ特に違和感なく使えるよ
まぁDebianなのでパッケージが安定志向だから古めのパッケージであることが多いものの、DebianのリポジトリにはFlatpakが提供されてるんで最近のパッケージ使いたければFlatpakを用いれば良い
問題があるとするならば、ChromeOSのDebian側からAndroid、というか階層として同レベルの仮想環境にあるAndroidがデフォルト状態で見えないということくらいか。ネットワーク設定でどうにか出来るかも知れんけどね
わざわざChromebookで複雑なネットワーク組むやつはネットワーク畑のやつだろうし自己解決しろって話ではある
iPadと比較したらiPadは仮想環境すら組めないので勝負の土俵にすら上がれてないわけだから学生が学習端末としてChromeOSを選ぶのは理解できなくもない
仕事でChatGPTに聞いたりCopilotを使うことはあるけれど使いこなしている気はしていない。
でも巷ではMCPだとかなんだと色々な便利ツールが乱立しているようだ。
そこでAIアシスタントでコーディングを助けてくれる環境を整えていきたい。
月1万円以内なら課金したいと思っている。
ある日突然ホムペが閉鎖されていることにきづく
どうもGitHubのプランが何者かによって変えられたと気づく （team to free)
元に戻してほしいと何度もGitHub側とやりとり ← いまここ
GitHub を利用した国内のエンジニア評価プラットフォームの 2 つに登録していたが、ある時期からこれらのサービスでのスコアが極端に低下した。これは決して自分の技術力や活動が落ちたわけではなく、むしろ逆で、GitHub での貢献が増えすぎたために正しく評価されなくなったという事態が発生した。
GitHub を利用した国内のエンジニア評価プラットフォームはGitHub のコントリビューション数やプルリクエスト数をもとに標準偏差や 1.0 - 5.0 でスコアを算出している。しかし、一定以上の貢献数を超えるとGitHub を利用した国内のエンジニア評価プラットフォームのシステムが適切にデータを取得できなくなり、コントリビューション数やプルリクエスト数が「0」として計上されてしまうという不具合が発生していた。
具体的にいうとコントリビューション数の累計や累計のプルリクエスト数、その時期毎の高い標準偏差に従って付与されるバッジを多数所持していたにも関わらず、突如として標準偏差が 40、プルリクエスト数は 0 と評価を受けた。これは明らかに技術力の変化ではなく、システムの不具合によるもので、問い合わせした際も彼らからのメールの文中には「不具合」と記載されていた。だが、何ヶ月経ってもこの問題は修正されることはなかった。
もう一つのGitHub を利用した国内のエンジニア評価プラットフォームでも同様の不具合が発生しており、コントリビューター数・コミット数が多い大規模OSSリポジトリへの貢献は評価が「0」になるという不具合があった。問い合わせたところ「不具合により取得不可能」との回答があったが、こちらもいくら待っても改善されなかった。
厄介なのはこれらのGitHub を利用した国内のエンジニア評価プラットフォームは彼らの評価するスコアを使って組織の人事に対してスカウトサービスを提供していることだ。
このままこれらのGitHub を利用した国内のエンジニア評価プラットフォームに自分自身を登録していると低い評価を受けるため、**自分のGitHub 貢献を正しく可視化できるツールを使う** という考えに至った。
具体的には、
これらのツールではGitHub を利用した国内のエンジニア評価プラットフォームと異なり、大規模OSS に対する貢献も正しく算出されており、GitHub を利用した国内のエンジニア評価プラットフォームにおける評価とはまったく異なる評価結果を表示していた。
GitHub を利用した国内のエンジニア評価プラットフォームを利用しなくなったことで、日本企業からのスカウトはほぼゼロになった。
一方で、github-readme-stats やOSS Insight による私の活動を見た海外企業からのオファーが増えるようになった。
これはエンジニア評価の仕組みが日本と海外で大きく異なることを示しているように思えた。
この経験を通じて感じたのは、「今いる環境で正しく評価されないなら、今いる環境外に向けて事実を示せば良い」ということだ。これは転職やキャリアだけでなく、会社での評価にも通じる。
ただし、これは両刃の剣でもある。
自分の技術を客観的に評価してもらえる環境に出会える可能性があるということは、逆にいえば、能力を過剰に盛っている場合は、事実ベースで評価されるため、かえって評価が下がることにもつながる。
特に「自称ハイスキルエンジニア」が、GitHub やOSS での実績がない場合、むしろ評価が下がる可能性もある。だからこそ、どこでも通じる実力を磨き、客観的なデータを元に自分の市場価値を示せるようにしておくことが重要だ。
1.GitHub を利用した国内のエンジニア評価プラットフォームは大量のコントリビューションを持つエンジニアを正しく評価できない不具合があり、数ヶ月単位でその不具合は修正されていない
2.GitHub のデータ(github-readme-stats,OSS Insight)を使うことで客観的な評価が可能になる
3.GitHub を利用した国内のエンジニア評価プラットフォームを使わなくなったことで日本企業からのオファーはなくなったが、海外企業からのオファーは非常に増えた
4. これは、今いる会社での評価にも通じる問題であり、環境が適切に評価してくれないなら、外に向けて客観的な事実を示せば良い
5. ただし、実力を過大評価されるようにしている場合、客観的な事実での評価によってむしろ厳しくなる可能性がある
GitHubリポジトリにデータと結果が用意されており、学術論文 (AP) の基盤はしっかり整っているようですが、モチベーションと優先順位付けに苦労しています。これを分解して、生産性とモチベーションを維持するための持続可能な計画を立てましょう。
プロセスをゲーム化 (5つのAP を完了するたびに「バッジ」を目指すなど) すると、もっと楽しくなりますか? これに楽しみの要素を加えるための戦略を検討できるかどうかお知らせください。
学生のやる気を引き出して質を維持するのは大変です。体系的な問題と個人の問題が混在する中で、あなたはその問題に取り組んでいるようです。一人では全体的な傾向を変えることはできませんが、説明責任を育み、研究室の状況を改善するために実行できるステップはあります。ブレインストーミングしてみましょう:
これらのアイデアのどれかが学生の心に響きましたか?必要に応じて、ルーブリック、ワークショップの議題、
SakanaAI チームは、完全にAI で生成された学術論文を発表して話題を呼びました。これは、生成AI の能力における重要なマイルストーンです。「TheAI Scientist-v2」と呼ばれる彼らのAI は、人間の介入なしに、独自に仮説を立て、実験を行い、データを分析し、原稿全体を執筆しました。この成果は、AI が研究と執筆のプロセスを効率化し、あなたのような研究者の時間と労力を節約できる可能性を示しています。
あなたの状況では、生成AIツールを活用することがゲームチェンジャーになる可能性があります。ワークフローに統合する方法は次のとおりです。
これらのアイデアを実装するための特定のツールや戦略を検討してみませんか?さらにサポートできる方法をお知らせください。
先延ばしは確かに手強い敵ですが、構造化されたアプローチといくつかの心理的トリックを使えば、物特性の公開プロジェクトを前進させることができます。ToDoリストを効果的に処理する方法は次のとおりです。
リストにはすでにタスクが示されていますが、一部 (「最初の拡張機能の実装に重点を置く」など) は範囲が広すぎるようです。さらに、具体的で実行可能なステップに細分化します。例:
タスクが小さいほど、気が遠くなるような感じがなくなり、達成しやすくなります。
---
重要度または緊急度に基づいて、優先度レベル (高、中、低など) を割り当てます。勢いをつけるために、優先度の高いタスクから先に処理します。例:
---
あなたが言及したブログに基づいて、役立つと思われるモチベーションを高めるコツを以下に示します。
---
各タスクに 2 分だけ費やすことから始めます。多くの場合、単に開始するだけで、先延ばしの惰性を克服できます。
---
各タスクに特定の時間をスケジュールします。たとえば、次のようになります。
---
---
進捗状況を誰か (同僚、友人、または私のようなAI でさえも!) と共有します。更新することがわかっていると、軌道に乗るモチベーションを維持できます。
---
現在のToDo の優先順位付けをお手伝いしたり、開始するための毎日のスケジュールを提案したりしますか?先延ばし癖を克服しましょう!Gu
おっしゃることはわかります。集中力が必要と思われるタスクは、小さなステップで管理できる場合でも、達成不可能に感じられる精神的な障壁があるようです。同時に、PCクラスターの構築などのタスクは、その精神的な障壁を利用しないため、より簡単に感じられます。幸いなことに、この認識は、「集中力を要する」タスクに合わせた戦略で変えることができます。方法は次のとおりです。
---
---
---
---
---
---
---
データ分析タスクをさらに小さなマイクロステップに分割しましょうか?PCクラスターを構築するのと同じくらい簡単に管理できます! 一緒にやりましょう。
提供されたテキストに基づいて、先延ばしを克服するためのより詳細なステップバイステップのガイドを以下に示します。
---
午前中は頭がクリアで、疲労や昼食後によく起こる眠気に気を取られる可能性が低くなります。これは、執筆や問題解決など、集中力を必要とするタスクに最適な時間です。
1. 最も精神力を必要とするタスク (ブレインストーミング、コーディング、データ分析など) を特定します。
2. これらのタスクを 1 日の早い時間にスケジュールします。理想的には、起床後の最初の 1 ～ 2時間です。
生成AI の Agent機能によるIT業界へのインパクトが大きそうでワクワクしてる。
ただ、中長期的なサービスの開発・運用は、生成AI の能力ではまだ厳しい。
リポジトリに乗っかる情報のみでは、現実に提供するサービスのコンテキスト全てを網羅できないから。
生成AI 側も無策ではなく、Cline の Memory Bank や Cursor Rules により、サービスの情報をドキュメントとして参照可能にすることでコンテキストの貧弱さをカバーしているが、まだ厳しい。
生成AI が読みやすい、正確な情報を持つドキュメントを整備する必要がある。
結局のところ、中長期的なサービス運用の領域においては、継続開発しやすい設計する良い開発者が必要と思った。
ただ、 PoC や中小規模サービスの開発生産性が爆速になるのは将来的に避けられない。
開発者のうち、コーディング領域しかスキルを持たない人は淘汰されるだろう。
俺は、のほほんと開発者として過ごしてきた。
やる気のある時期は勉強したり、無い時は全くしなかったり。
