xguru 18 분 전 | 親コメント | トピック: GitHubの可用性に関するアップデート (github.blog) エラーがあまりにも多いので、取り急ぎいったん告知を出したということですね。 でも、あまりにも遅すぎるのではという気もしますが…。 すでにエラーが多すぎて、みんな離脱すると話しているところなのに つらい winkagn 30 분 전 | 親コメント | トピック: DeepSeek-V4論文読解まとめ - ノ・ジョンソク (youtube.com) 人々は中国製だから信頼できないというふうに言ったりしますが、私はDeepSeekが研究し公開する方向で、試行錯誤まで公開していることについては本当にありがたいと思います。 aldlfkahs 31 분 전 | 親コメント | トピック: stitchが流行らせた(?)DESIGN.mdを集めたサイト (getdesign.md) AIにフロントエンドを任せるときに良さそうですね。共有ありがとうございます。 neostom432 1 시간 전 | 親コメント | トピック: Claude に実装させて Codex に粗探しさせる — 2つのエージェントを1つのリポジトリで分担させる実務パターン (rubric.im) 私たちは両方を使う形に落ち着きました。 スラッシュコマンドのフロー内に Codex のクロスレビュー・フェーズを組み込み(/ship の中で企画 → 実装 → 検証 → Codex レビュー → 報告という流れ)、同時に pre-push hook にも同じレビューを仕込んでいます。スラッシュコマンドだけだと急いでいるときにそのまま push してレビューが抜けますし、hook だけだと push 直前になって初めて結果が出るので遅いです。 どちらの経路でも Codex CLI を直接呼ばず、ひとつラップした bash スクリプト(codex-review.sh)を両側からまったく同じように呼び出します。そのスクリプトがタイムアウト、認証チェック、シークレットチェック、出力フォーマットを一か所で処理してくれるので、スラッシュコマンドでも hook でも呼び出し側がすっきりします。 重要なのは、Codex のレビュー結果では絶対にブロックしないという点です。CLI が落ちた場合でも、CRITICAL が出た場合でも、push はそのまま通し、結果だけを出力します。一度でもブロックするようにしてしまうと、Codex が実際には問題のないコードを誤検知したときに、ユーザーが push するために hook を回避するオプション(git push --no-verify)を使うようになり、これが習慣化すると hook が設定されていても動いていないのと同じ状態になります。なので、ブロックが必要な検査(lint・type・test、シークレットファイルの push)は別のゲートに分離し、モデルの意見は参考用にとどめています。 スクリプト・スラッシュコマンド・hook の本文はトラック 4〜6 チャプターにそのまま入っているので、参考にしていただけると思います。 ku9cu 1 시간 전 | 親コメント | トピック: Claude に実装させて Codex に粗探しさせる — 2つのエージェントを1つのリポジトリで分担させる実務パターン (rubric.im) こういうやり方をしている人がいるそうですが、どんな運用なのか気になります。 2つのツールを別々のエージェントとしてまとめるのではなく、開発者が必要なときにそれぞれ直接呼び出しているのか、 それとも Git Hook 時に自動で Codex がレビューするような設定にしているのか、気になります。 carnoxen 8 시간 전 | 親コメント | トピック: GitHub障害 - リポジトリのプルリクエスト結果が不完全になる問題に関するGitHubのインシデントレポート (githubstatus.com) ああ、もう…… unsure4000 8 시간 전 | 親コメント | トピック: 生理追跡アプリFlo、ユーザーデータをMetaに販売していた事実が確認される (femtechdesigndesk.substack.com) 最近はMetaが少しはマシに見えてきていたのに、Metaへの怒りをまた補充して帰ります。 少し別の話ですが、最近のOSのlockdownもMetaがロビー活動した結果だという話もありましたが……創業ストーリーからその後の一つひとつの行動まで、本当に倫理観なんてかなぐり捨てたようですね cherrycoder 11 시간 전 | 親コメント | トピック: DeepSeek V4 Proモデルが期間限定で75%割引に (api-docs.deepseek.com) LLM事業者は、一般ユーザーが無料またはサブスクリプション方式で使う「消費者向けサービス」のデータについては、モデル改善のために基本的に収集・学習する傾向があります。一方、企業や開発者が費用を支払って利用するAPIや企業向けサービスのデータは、ほとんどの場合、契約を通じて学習に使われないよう保護されています。 ここで一つ重要な問題を押さえておく必要があります。まさに「有料製品は本当に私のデータを学習にまったく使わないのか?」という根本的な疑問です。 OpenAIの企業向けサービスは、契約上データを学習に使用しないと明記されていますが、その「約束」を技術的にどう検証し、法的・制度的にどう担保できるのでしょうか。現時点では、私たちがOpenAIの学習パイプラインを直接監視することはできないため、これは全面的に事業者の倫理意識と契約書に依存せざるを得ない領域です。 「私のデータがモデルの知識として溶け込むリスクはないのか?」という同じ問いは、DeepSeekだけの問題ではなく、予算や必要性に応じて、より安全な契約条件(例:API、企業向けプラン)を「購入」するか、あるいは技術的完全性のために自らモデルをホスティングする以外、完全な解決策がないという課題を抱えています。 「中国のLLMだから自動的に個人情報を抜き取る」というのは誇張された表現であり、データ活用に関する構造的リスクは米国のLLMでも大きくは変わりません。重要なのは、サービスの種類と契約条件を丁寧に確認し、自分たちのデータを守るために費用を支払うか、技術的な代替手段(セルフホスティングなど)を選ぶことです。 cgl00 12 시간 전 | 親コメント | トピック: GitHub障害 - リポジトリのプルリクエスト結果が不完全になる問題に関するGitHubのインシデントレポート (githubstatus.com) GitHub、最近は問題が多いですね yeobi222 14 시간 전 | 親コメント | トピック: Claude Codeが書いたコードの所有者は誰か? (legallayer.substack.com) 含まれます undeadx1 15 시간 전 | 親コメント | トピック: Claude Codeが書いたコードの所有者は誰か? (legallayer.substack.com) コードは保護の対象になり得るのか? idpravus 15 시간 전 | 親コメント | トピック: Warp、ターミナルベースのAgentic Development Environmentをオープンソース化 (github.com/warpdotdev) fallback font をサポートしていないので、日本語の表示が物足りないです minsuchae 17 시간 전 | 親コメント | トピック: GitHub Copilotが従量課金制に移行 (github.blog) 私も返金しましたね... AIクレジットもロールオーバーされないし...明確な基準もなくトークン使用量と利用時間(Thinkしているときにかかる部分)を適用するというのが... 従量制にするならするで... いっそ利用料で計るなら一定の有効期間を設けてロールオーバーできるようにすべきなのに... そうなると使う理由がないですよね... ChatGPT、Claude、Geminiより優れている理由は...? 私は年額で使っていて、メインではないもののちょこちょこ使っていたんですが...あまりにも大きな不意打ちに感じます。年額ユーザーには少なくともその有効期間が維持されるまでは既存価格のままにすべきなのに、急に価格が上がったからと利用制限をもっと厳しくしてしまうなら... 年額払いの意味を忘れたように思えます... 先にまとめて受け取る代わりに少し多めにプロモーションを付けて、その期間中に顧客獲得をするものなのに... jimmy2056 20 시간 전 | 親コメント | トピック: Warp、ターミナルベースのAgentic Development Environmentをオープンソース化 (github.com/warpdotdev) 良いのですが、普通のターミナルを使っていた状態から移行しようとするとかなりもたついて、結局使わなくなりました。 jimmy2056 20 시간 전 | 親コメント | トピック: ハーネスエンジニアリング:モデルより重要な作業環境設計の時代 (addyosmani.com) モデルが優れていれば、ハーネス設計の負担も軽くなります。 xguru 21 시간 전 | 親コメント | トピック: YCのRequests for Startups - 2026年夏 (ycombinator.com) 四半期ごとに出ていますね。 確かに YCのRequests for Startups - Summer 2025 のときもAIは多かったですが、 今年に入ってからは、AIの適用がよりバーティカルやエンタープライズ寄りに近づいてきたように思います。 carnoxen 21 시간 전 | 親コメント | トピック: GhosttyがGitHubを離れます (mitchellh.com) すでに別の場所(Codeberg など)へ移った人たちは、今回の事態を見て、移っておいて本当によかったという思いをいっそう強くするのではないでしょうか。 xguru 21 시간 전 | 親コメント | トピック: DeepSeek-V4論文読解まとめ - ノ・ジョンソク (youtube.com) 修正しておきました ragingwind 21 시간 전 | 親コメント | トピック: DeepSeek-V4論文読解まとめ - ノ・ジョンソク (youtube.com) ありがとうございます。修正が必要ですね。 junghwanlee 22 시간 전 | 親コメント | トピック: DeepSeek-V4論文読解まとめ - ノ・ジョンソク (youtube.com) ノ・ソンフンさん→ キム・ソンヒョンさんです コメントをさらに読み込む
エラーがあまりにも多いので、取り急ぎいったん告知を出したということですね。
でも、あまりにも遅すぎるのではという気もしますが…。
すでにエラーが多すぎて、みんな離脱すると話しているところなのに つらい
人々は中国製だから信頼できないというふうに言ったりしますが、私はDeepSeekが研究し公開する方向で、試行錯誤まで公開していることについては本当にありがたいと思います。
AIにフロントエンドを任せるときに良さそうですね。共有ありがとうございます。
私たちは両方を使う形に落ち着きました。
スラッシュコマンドのフロー内に Codex のクロスレビュー・フェーズを組み込み(
/shipの中で企画 → 実装 → 検証 → Codex レビュー → 報告という流れ)、同時に pre-push hook にも同じレビューを仕込んでいます。スラッシュコマンドだけだと急いでいるときにそのまま push してレビューが抜けますし、hook だけだと push 直前になって初めて結果が出るので遅いです。どちらの経路でも Codex CLI を直接呼ばず、ひとつラップした bash スクリプト(
codex-review.sh)を両側からまったく同じように呼び出します。そのスクリプトがタイムアウト、認証チェック、シークレットチェック、出力フォーマットを一か所で処理してくれるので、スラッシュコマンドでも hook でも呼び出し側がすっきりします。重要なのは、Codex のレビュー結果では絶対にブロックしないという点です。CLI が落ちた場合でも、
CRITICALが出た場合でも、push はそのまま通し、結果だけを出力します。一度でもブロックするようにしてしまうと、Codex が実際には問題のないコードを誤検知したときに、ユーザーが push するために hook を回避するオプション(git push --no-verify)を使うようになり、これが習慣化すると hook が設定されていても動いていないのと同じ状態になります。なので、ブロックが必要な検査(lint・type・test、シークレットファイルの push)は別のゲートに分離し、モデルの意見は参考用にとどめています。スクリプト・スラッシュコマンド・hook の本文はトラック 4〜6 チャプターにそのまま入っているので、参考にしていただけると思います。
こういうやり方をしている人がいるそうですが、どんな運用なのか気になります。
2つのツールを別々のエージェントとしてまとめるのではなく、開発者が必要なときにそれぞれ直接呼び出しているのか、
それとも Git Hook 時に自動で Codex がレビューするような設定にしているのか、気になります。
ああ、もう……
最近はMetaが少しはマシに見えてきていたのに、Metaへの怒りをまた補充して帰ります。
少し別の話ですが、最近のOSのlockdownもMetaがロビー活動した結果だという話もありましたが……創業ストーリーからその後の一つひとつの行動まで、本当に倫理観なんてかなぐり捨てたようですね
LLM事業者は、一般ユーザーが無料またはサブスクリプション方式で使う「消費者向けサービス」のデータについては、モデル改善のために基本的に収集・学習する傾向があります。一方、企業や開発者が費用を支払って利用するAPIや企業向けサービスのデータは、ほとんどの場合、契約を通じて学習に使われないよう保護されています。
ここで一つ重要な問題を押さえておく必要があります。まさに「有料製品は本当に私のデータを学習にまったく使わないのか?」という根本的な疑問です。
OpenAIの企業向けサービスは、契約上データを学習に使用しないと明記されていますが、その「約束」を技術的にどう検証し、法的・制度的にどう担保できるのでしょうか。現時点では、私たちがOpenAIの学習パイプラインを直接監視することはできないため、これは全面的に事業者の倫理意識と契約書に依存せざるを得ない領域です。
「私のデータがモデルの知識として溶け込むリスクはないのか?」という同じ問いは、DeepSeekだけの問題ではなく、予算や必要性に応じて、より安全な契約条件(例:API、企業向けプラン)を「購入」するか、あるいは技術的完全性のために自らモデルをホスティングする以外、完全な解決策がないという課題を抱えています。
「中国のLLMだから自動的に個人情報を抜き取る」というのは誇張された表現であり、データ活用に関する構造的リスクは米国のLLMでも大きくは変わりません。重要なのは、サービスの種類と契約条件を丁寧に確認し、自分たちのデータを守るために費用を支払うか、技術的な代替手段(セルフホスティングなど)を選ぶことです。
GitHub、最近は問題が多いですね
含まれます
コードは保護の対象になり得るのか?
fallback font をサポートしていないので、日本語の表示が物足りないです
私も返金しましたね...
AIクレジットもロールオーバーされないし...明確な基準もなくトークン使用量と利用時間(Thinkしているときにかかる部分)を適用するというのが...
従量制にするならするで...
いっそ利用料で計るなら一定の有効期間を設けてロールオーバーできるようにすべきなのに...
そうなると使う理由がないですよね...
ChatGPT、Claude、Geminiより優れている理由は...?
私は年額で使っていて、メインではないもののちょこちょこ使っていたんですが...あまりにも大きな不意打ちに感じます。年額ユーザーには少なくともその有効期間が維持されるまでは既存価格のままにすべきなのに、急に価格が上がったからと利用制限をもっと厳しくしてしまうなら...
年額払いの意味を忘れたように思えます...
先にまとめて受け取る代わりに少し多めにプロモーションを付けて、その期間中に顧客獲得をするものなのに...
良いのですが、普通のターミナルを使っていた状態から移行しようとするとかなりもたついて、結局使わなくなりました。
モデルが優れていれば、ハーネス設計の負担も軽くなります。
四半期ごとに出ていますね。
確かに YCのRequests for Startups - Summer 2025 のときもAIは多かったですが、
今年に入ってからは、AIの適用がよりバーティカルやエンタープライズ寄りに近づいてきたように思います。
すでに別の場所(Codeberg など)へ移った人たちは、今回の事態を見て、移っておいて本当によかったという思いをいっそう強くするのではないでしょうか。
修正しておきました
ありがとうございます。修正が必要ですね。
ノ・ソンフンさん→ キム・ソンヒョンさんです