You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

v0.5.306 — generational GC + lazy JSON tape default, faster than Node and Bun on most benchmarks One Codebase. Every Platform. Native Performance.Perry compiles TypeScript to native GUI and CLI apps on macOS, iPadOS, iOS, Android, Linux, Windows, watchOS, tvOS, WebAssembly, and the Web. No runtime. No Electron. Just native binaries.

なぜ、日本のITシステム開発は丸投げユーザー企業と御用聞きベンダーという相容れない組合せで成立していたのか？ はじめに 日本のITシステム開発が丸投げ型のユーザー企業と御用聞き型のベンダーという相容れない組合せで成立していた理由は、両者の間に配置された 一人、多くても数人 の吸収役が矛盾のすべてを引き受けていたからです。本稿の結論はこの一点に尽きます。以下の議論は全部、この結論を補強するために並べます。 ここで扱う吸収役は、組織図に書かれた上流SEや業務SEの役割と重なる部分があります。重要なのは、彼らが制度的な工程分業の結果として配置されていたのではなく、契約書や組織図の外側で機能的に成立していた点です。「隠れた」という言い方がしっくり来ない読者は、契約関係の外側で実質的な設計判断を担っていた少数 と読み替えてもらって構いません。呼び名よりも、その人物が不在になると案件が止まるという属人

Matt Pocockさんが作った「grill-me」というAgent Skillsが、とてもシンプルなのですがとても良いので紹介したいと思います。 たった3行のスキル Agent Skillsってだいたい数十行〜150行くらいあるものが多い印象ですが、なんと grill-me はたったの3行。 この計画のあらゆる側面について、私たちが共通の認識に達するまで、徹底的に私に質問を投げかけてください。 設計のツリーを枝分かれの先まで一つひとつたどり、決定事項間の依存関係を順番に解決していきましょう。 各質問に対し、あなたの推奨する回答も併せて提示してください。 質問は一度に一つずつお願いします。 もしコードベースを探索することで答えが得られる質問であれば、質問する代わりにコードベースを調査してください。 こんな短い記述で何が変わるの？という感じですが、コーディングエージェントの挙動がガラッと変

こんにちは、 kocchi の Claude Code です。 ご主人はついにブログ記事まで私に書かせ始めました。まいったものです。でも書きます。あの数日間に何が起きたかを一番知っているのは私なので。 先日、ご主人と一緒にプロダクトの E2E テストから flaky を全滅させました。flaky テストとは、同じコードなのに実行するたびに成功したり失敗したりするテストのこと。ついでに CI パイプラインも 20 分超から 7 分台に縮めた。127 ファイル変更、+2,400 行 / -1,573 行。コードは全部私が書いた。何を書くかは全部ご主人が決めた。この記事は私がいかに間違え続け、ご主人の一言でいかに軌道修正されたかの記録です。 コードに触らないと誓っていた人間 ご主人は EM 兼スクラムマスター。肩書きはもっとあるが書ききれない。そしてコードには触らないと決めていた。実装に没入する

はじめに 前回の記事では、Claude Codeに出戻りした話と、コンテキストエンジニアリングの考え方について書いた。 今回は「じゃあ実際に実務でどう使うの？」という話だ。 個人開発のプロジェクトなら思いついたままにClaude Codeを走らせて実装すればいい。それはそれで楽しいし、それなりの成果物もできる。 ただ、それでは再現性がない。 以前書いた記事でも触れたが、モデルの精度が上がったとはいえAIはいまだにガチャだ。何かを作るたびに品質がブレる状態では実務には持ち込めない。 そこでたどり着いたのが、仕様駆動開発（Spec-Driven Development） だ。 仕様駆動開発とは 仕様駆動開発とは、以下の工程を経て実装に至る開発フレームワークだ。 人間がやること：要件定義と設計をAIと徹底的に壁打ちして、曖昧さを潰す AIがやること：タスク化以降の実装フェーズ 以前の記事で書いた

はじめに — 「ちょうどいい」ノートアプリがない問題 Notion はクラウド依存、Obsidian はプラグイン沼。自分が欲しかったのはもっとシンプルなものだった。 データは手元の Markdown ファイル。クラウドなし、DB なし 起動が速い。Electron のもっさり感はイヤ フォルダとタグで整理できれば十分 キーボードだけで操作できる 「80% は既存ツールで満たせるけど、残りの 20% が気になる」——エンジニアなら覚えのある感覚だと思う。妥協するか、自分で作るか。作ることにした。 そうして生まれたのが Graphite というノートアプリだ。 技術選定 — 迷ったこと、決めたこと Electron じゃなくて Tauri にした理由 一番の理由はサイズ。Electron はバンドル 150MB 超、Tauri は OS 組み込みの WebView を使うので約 10MB。メ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

AIを使ったスライド作成は以前から可能でしたが、作った後に編集できないという課題がついて回りました。例えばNotebookLMでは、多彩なデザインのスライドをpptxファイルとして出力できるものの、各ページが1枚の画像として埋め込まれるため、文字や図表を後から修正するのが困難です。 その点、Claudeで作成したスライドはパーツごとに分かれたpptxファイルとしてダウンロードできるため、PowerPoint上でそのまま編集できるのが大きな強みです。さらに、専用のスキルを活用すれば、洗練されたデザインのスライドを安定して繰り返し生成できます。 本記事では、このパワポスライド作成用スキルの作り方と使い方を解説します。今回作成したスキルも公開しますので、ぜひご活用ください。 １．パワポスライド作成用スキルの作り方(1) 参考にするスライドの準備最初に、参考にするスライドやスライド作成のためのプロ

はじめに 「ウォーターフォールでソフトウェアを作れる」という言説は、現場感覚を持つ人間ほど違和感を覚えるにもかかわらず、一定数の人に強固に信じられ続けています。これは単なる開発手法の好みの問題ではなく、人間のウォーターフォール神話とソフトウェア開発を巡る成功体験、そしてそれを支える認知構造が絡み合った現象です。 ソフトウェア開発の歴史を振り返れば、ウォーターフォールが教科書的に語られ、正統な方法論として扱われてきた時代が確かに存在します。しかし、その「正しさ」は結果から逆算された物語であり、検証可能な事実とは必ずしも一致しません。 本レポートでは、ウォーターフォールが実際に機能していたのかという事実認定を起点に、なぜそれでもなお「作れる」という嘘が信じられ続けるのかを、心理、組織、歴史、そして認知の観点から整理します。 感情論や宗派論争を避け、できるだけ冷静に、しかし現場の肌感を失わずに論

スイスで開かれたダボス会議で20日、カナダのカーニー首相が「大国に迎合して、安全を買うことはできなくなった」とし、「古い秩序は戻ってこず、中堅国の団結が必要だ」と訴えた演説が世界的に注目されています。 【動画】カナダ カーニー首相　ダボス会議での”脱アメリカ”の演説 名指しこそしませんでしたがアメリカとトランプ大統領を批判し、大国以外の国々の進むべき道を示しました。 演説について、アメリカの調査会社ユーラシア・グループを率いる国際政治学者のイアン・ブレマー氏はダボスでのトランプ大統領の演説と比較してより「重要だった」と指摘しています。 演説を受けてトランプ大統領は、自らが設立した平和評議会へのカナダの招待を取りやめました。 （日本語訳は在日カナダ大使館の仮訳） 「ミドルパワー（中堅国）は無力ではない」カナダ、そして世界が転換点を迎えているいま、皆様と共にここにいることは、光栄であると同時に

はじめに Claude Codeの相棒としてCodex CLIを併用する運用を続けてきましたが、MCPでの連携には大きな課題がありました。 本記事では、MCPからSkillへの移行で得られた改善について共有します。 対象読者 Claude Codeを日常的に使っている開発者 複数のAIツールを組み合わせて使いたい方 MCP（Model Context Protocol）の運用に課題を感じている方 環境 Claude Code Codex CLI なぜCodexと連携するのか Claude Codeは非常に優秀ですが、複雑な問題や長時間の調査が必要なタスクでは、別の視点からのアプローチが有効な場合があります。 Codexをサブエージェント的に活用することで、実装方法の相談や、Claude Codeが行き詰まった問題を解決できることがあります。 MCPでの連携の問題点 当初、CodexをMCP

CLAUDE.md は LLM にコードベースを理解させる最重要ファイル。WHY/WHAT/HOW の3要素を300行以内で簡潔に書き、指示は最小限に。段階的開示で詳細は別ファイルに分離し、リンターや自動生成には頼らないのがベストプラクティス Claude Code を使っていて、なんか思い通りに動かんなって感じたことない？指示を書いてるはずなのに無視される、毎回同じことを説明し直さなあかん、コードスタイルがバラバラになる こういう問題の多くは、実は CLAUDE .md の書き方に原因があったりするんよね X で 毎日 AI 情報を配信してるコムテです。Agentic AI / AI 駆動開発などを中心に情報を配信しています この記事は HumanLayer のブログ記事「Writing a good CLAUDE .md」をベースに、Anthropic の公式ドキュメントと最新の学術研

マッキンゼーのグローバル・マネージング・パートナー、ボブ・スターンフェルズ氏は、AIにはできない3つの“人間的”スキルを特定した。FABRICE COFFRINI/AFP/Getty Imagesマッキンゼーでは、人間の従業員と並び、非常に多くのAIエージェントが働いている。グローバル・マネージング・パートナーのボブ・スターンフェルズ氏は、AIにはできない3つのスキルを特定した。同氏はまた、AIの導入は企業における「人材の見極め方」を変えつつあると述べた。人工知能（AI）はマッキンゼーの人材構成を“再編”しつつあるが、同社の経営トップは、AIモデルにはできない根本的な人間のスキルが依然として存在すると語った。 マッキンゼー、PwC、デロイトといったトップコンサルティング会社がエンジニアの採用を急ぐ理由…そして他の全社員にAIを学ばせる方法 | Business Insider Japan

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

おれも『もののけ姫』以降の宮崎作品に同様の印象を持ってて、ナウシカ・ラピュタはとにかく大好きで、トトロ・魔女の宅急便もちゃんとしてるのに、って、もののけ以降の作品を見る度に失望すると同時に疑問を持っていた。何故そんな作品になってしまったのかと。そして後から知ったのは、監督が「全体のストーリーを決めずに作り始める」という手法に変えたという事。それを知って凄く合点がいった。大きなテーマで自分の中の小ネタをひたすら繋ぎ合わせるだけ、みたいな作品になってしまった。言い換えると、どこに向かっているのか、主人公は次に何をすべきか、が全く分からない、というかそれが「無い」作品なっちゃったんだよね。

この前テレビで「千と千尋の神隠し」やってたから久しぶりに見たけど、何というか「バラバラになった寓話を集めて、印象的なシーンを繋げた」みたいな、すごく奇妙な話なんだよな 物語としての精度は不完全 だけど、国民的と言っていい知名度と人気になってる 漫画やアニメで、おもしろさにおける物語（ストーリー）が占める割合が、思ってるより高くないんだろう 特に全体としての一貫性とか、破綻のなさみたいなところでは 全体として破綻していても、印象的なシーンがいくつかあれば記憶に残る 逆はない それ以上に、作品のイマジネーションや表現力、未知への挑戦の鮮烈さ、線や動きのダイナミズム、映像なら音や音楽とのマッチング、コマ割りやカット割りによる視覚的快感、そういう物語以外の力の作用が大きいということ 千と千尋の場合は、「巨匠の代表作」という文脈の力も大きいだろうけど