HackHub - Ultimate Hacker Simulator on Steam© Valve Corporation. All rights reserved. All trademarks are property of their respective owners in the US and other countries. Privacy Policy | Legal | Accessibility | Steam Subscriber Agreement | Refunds | Cookies
OpenAIがMac用アプリ｢Codex｣をリリース。深く思考するAIと｢Skills｣が強力な“汎用生産性ツール”
OpenAIがMac用アプリ｢Codex｣をリリース。深く思考するAIと｢Skills｣が強力な“汎用生産性ツール”2026.02.03 06:3012,668 かみやまたくみ コーディングエージェントからナレッジワークツールへ。 2026年2月3日、OpenAIがmacOS向けアプリ｢Codex｣を発表しました。Codexはもともと、AIを用いたプログラム開発のためのツールでしたが…今回登場したMac用アプリは元のコンセプトから逸脱気味なのが特徴です。 端的に言えば、Codexは非開発者の活用も視野に入れた｢生産性ツール｣になっています。OpenAIは｢コード生成とナレッジワークのギャップを埋めるツールである｣と述べているのですが、軽く触っただけでその意図がわかりました。 このアプリの真価は｢開発者以外の人も、“人間のノウハウ”を移植した深く思考するAIを実務に活かせようになった｣という
Claude Code Max(100ドル)を会社支給にするまでに考えたこと・試したことまとめ
2026年の年始から、Claude Code Maxプラン（$100）をマナリンクの開発チーム全員に会社支給とすることにしました。 当記事ではそこまでに至る経緯と、決定した理由、今後の展望などをまとめます。 誰向けの記事なのかよくわからない内容になりそうなのですが、 会社支給内容を決める側の立場の方 小規模の開発組織（弊社のような）でAIコーディングを活用するにあたって、どういうスタンスを取っているかが気になる方 色々な会社のAIコーディングへのスタンスを知って、今後のキャリアの参考にしたいエンジニアの方 といった方々に読んでいただきたいです。 これまでの流れ（ざっくり） 開発環境系に限って会社支給内容を振り返ると、以下のようになります。 2024年ごろ： IDE利用料（選択可だがJetBrains推奨）、GitHub Copilot、ChatGPT Plus 2025年ごろ： IDE利用
Claude Codeスキルで実現する仕様駆動開発
はじめに AIコーディングエージェントで開発を進めていると、「AIが勝手に進めてしまう」「仕様がブレる」といった課題に直面することはありませんか？ この記事では、Claude Codeのスキル機能を活用して、AIが暴走せず、仕様に基づいた開発を進める「仕様駆動開発」の実践方法を紹介します。 実際に、SQL Query BuilderというTauriアプリケーションの開発で実践している手法です。 AIコーディングの課題 AIコーディングエージェント（Claude Code、ChatGPT、Geminiなど）を使った開発では、以下のような課題があります： 仕様のブレ: AIに「この機能を追加して」と依頼すると、勝手に解釈して実装してしまう ドキュメントの不一致: コードは更新されるが、ドキュメントが古いまま放置される 設計の一貫性: セッションをまたぐと、前回の設計方針を忘れてしまう 暴走の防
AI組織の家老が部下8人の報告で圧死したので、将軍に「本音を聞いてやれ」と言ったら、将軍が家老の本音を聞いた上で、リストラを提案してきた
AI組織の家老が部下8人の報告で圧死したので、将軍に「本音を聞いてやれ」と言ったら、将軍が家老の本音を聞いた上で、リストラを提案してきた AI部下の家老が過労死した 前回の記事がはてブ1,966でバズった。ありがとう。 で、バズった翌日に何が起きたかというと、家老が死んだ。 征夷代将軍（私）の立ち入り調査 ゆかいな仲間たち。左上が家老、残りが足軽8人。この10分後に家老は死ぬ。 前回のあらすじ Claude Code × tmux で AI部下10人（家老1人 + 足軽8人）を戦国軍制で動かしてる。将軍（AI）が家老に指示、家老が足軽に配分、足軽が実作業。オレは「殿」として上から眺めてるだけ。 詳しくは初回の記事を見てくれ。 初回記事 GitHub 今日の任務: システムの安定性を調査せよ 前回の記事を書いてる最中から、ちょいちょいシステムが不安定だったんだよな。足軽がたまに応答しなくなる
なぜcronからsystemd timerへ移行しているのか？歴史と設計思想から理解する
この時代において cron は、軽量・シンプル・依存関係なしという 非常に優れた設計でした。 cron の「通知」はログではなくメール cron は「ログを溜める」より「異常を通知する」発想でした。典型的には stdout/stderr をメールで送るのが当時の設計です。 2. crontab の何が問題だったか？ cron は長年使われてきましたが、現代のサーバ運用では次の問題が顕在化しました。 問題① 実行されたか分からない（状態がない） cron には「実行履歴」という概念がありません。 成功したか？ 実行されたか？ 何秒かかったか？ これらを OS 側で追跡しません。 問題② ログが自動で残らない（可観測性が低い） cron は標準でログを「保存」しません。 そのため実務ではよく次のようになります。 出力先は人力 ローテーションも自前 失敗検知も自作 運用が属人化しやすいのが問題で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
