はてなブックマーク

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 AIエージェントの性能を上げようとすると、まずモデル選定に目が行きます。 Opus 4.6にするか、Geminiにするか。ただ、2026年に入ってからの各社の発表やベンチマーク結果を見ていると、性能差を生んでいるのはモデルそのものではなく、モデルを包む周辺インフラのほうだという話が増えてきました。 この周辺インフラを指す言葉として、ハーネスエンジニアリングという概念が急速に広まっています。 ハーネスエンジニアリングとは何かPhil Schmidが書いた記事のアナロジーがわかりやすいです。モデルはCPUで、ハーネスはOSです。 CPUがどれだけ高性能でも、OSが貧弱ならパフォーマンスは出ません。同じように、LLMがどれだけ賢くても、コンテキスト管理やツール統合、メモリ管理、検証の仕組

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 Claude CodeやCodex CLI、Gemini CLIなど、AIエージェントにAgent Skillsを読み込ませて使う場面が増えてきました。SKILL.mdにドメイン固有の手順を書いておけば、エージェントのタスク完了率が上がります。Opus 4.6が出て、Agent Teamsが有効化されたりした今、カリカリにスキルをチューニングしている方も多いのではないでしょうか。 ただ、ふと考えてみると、このSkills自体をAIに書かせたらどうなるのか。メタ認知ができるなら、自分に必要な手順書を自分で書けるはずです。 この直感的な期待に対して、先日公開されたSkillsBenchという論文が参考になりました。 結論から言うと、LLMが自分で生成したSkillsは現時点では効果が確

Vibe CodingからAgentic Engineeringへ。トップエンジニアたちのAI開発プラクティス 皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 Claude Opus 4.6使ってますか？私も並列開発の手法などを取り入れてリサーチ作業などをしているのですが、ふとトップエンジニアたちがAIをどう使っているのか気になっていました。調べてみると、彼らのアプローチは大きく3つの流派に分かれつつも、共通で参考にできそうな点が多かったので、今回はその実践を整理してみます。 Vibe CodingからAgentic EngineeringへAndrej Karpathyが「Vibe Coding」という言葉を世に放ったのが2025年2月のことです。コードの存在を忘れてバイブスに身を委ねる、というあのフレーズは瞬く間に広まりまし

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 先週は"SaaS is Dead"というフレーズを見ない日はありませんでしたね。2026年2月、ソフトウェア株の時価総額が合計$1T（約150兆円）消失しました。HubSpotは-39%、Figmaは-40%と、ワークフロー系のSaaSが軒並み大きく下げています。 一方で、同じ週にCloudflareは2日で+24%上昇し、時価総額が$15B増えています。AnthropicのClawdbotがCloudflare上で動いていることがバイラルで広まりました。AIエージェントのインフラ需要を市場が再評価した形です。 この対比が象徴しているのは、SaaS全体が沈んでいるのではなく、AIによって伸びるSaaSと苦しくなるSaaSの構造が変わったということだと思います。AI生成コードは全体の

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 Claude CodeやCursorでフロントエンド開発をしていると、修正箇所の指示が伝わらない場面に遭遇します。「サイドバーの青いボタンをもう少し大きくして」と言っても、だいたいは問題ないですがたまに間違えることもあります。 毎回DevToolsを開いてセレクタをコピペするのは面倒です。この問題を解決するツールが最近いくつか登場しているので、今回はその中からAgentationを中心に紹介してみます。 画像でのAIへのフィードバックClaude Codeでもスクリーンショットは貼り付けられます。ターミナルに画像をドラッグ&ドロップするだけです。ただ、スクショだけでは課題もあります。 まずトークンコストの問題があります。画像はテキストに比べてトークン消費が大きく、何度もスクショを送

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__)です。 LlamaIndexのJerry Liuさんが「Files Are All You Need」という記事を公開していました。 AIエージェント界隈で「ファイル中心設計」が急速に支持を集めている印象があります。なぜ今、ファイルなのか。あくまで推測ですが、その理由はいくつかあると思います。 新規の学習コストがない1つめは、単純に学習コストの観点です。 LlamaIndexの記事では、LLMが膨大なコードベースで訓練されている点を強調しています。GitHubに上がっているコードの多くには`grep`や`ls`、ファイルの読み書きといった操作が含まれています。つまり、LLMにとってファイルシステムの操作は、わざわざ教え込む必要のない「既知の能力」になっています。 一方で、カスタムのMCPツ

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 先日vercel-labs/agent-browserがリリースされました。「トークン消費93%削減」という謳い文句を見て、どうやってそれを実現しているのか気になったので中身を読んでみました。パッと見はPlaywrightのラッパーに見えるのですが、実際にはAIエージェント向けの入出力設計がかなり練られていて、面白かったです。 従来のPlaywright MCPが抱える課題まず、なぜ新しいツールが必要だったのかを整理しておきます。 Playwright MCPは、ブラウザ自動化のデファクトスタンダードであるPlaywrightをMCPサーバーとして提供したものです。多機能なのですが、AIエージェントから使う場合にはいくつかの問題がありました。 ひとつはツールの数です。Playwri

私はこれとClaude Code on the Webを組み合わせて、モバイルから開発作業をトリガーする実験をしていました。スマホから複数のタスクを並列実行できます。 結果として、「トリガーする」ことは十分にできました。issueを投げて、Claudeに実装を任せて、PRを作らせる。この流れ自体は動きます。 ただ課題は感じていて、以下の２つです。 問題A：画面を見に行かないといけない最初に感じたのは、「結局、画面を見に行かないといけない」というストレスです。 Claudeがタスクを実行している間、私は別のことをしたいわけです。でも実際には、エラーが出ていないか、進捗はどうか、確認のために何度もスマホを開いてしまいます。 「タスクを投げたら放っておける」のが理想なのに、実態は「投げたけど何度も確認してしまう」状態になっています。 この問題はみなさんも日頃既に実感していると思いますが、モバイル

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 2025年後半あたりから、「長時間タスクを実行できるエージェント」についての議論が増えてきたように感じます。周辺技術が出揃ってきた中で、たまに目にするようになったキーワードが「Ambient Agent」です。この記事では、Ambient Agentとは何か、どの業務が置き換わりうるのか、技術的なキーファクターについて整理してみます。 Ambient AgentとはAmbient Agentは、バックグラウンドで常時稼働し、イベントストリームを監視して適切なタイミングで行動するAIシステムです。ユーザーからのプロンプトを待つのではなく、データ・ワークフロー・API・他のエージェントからのトリガーで起動します。 LangChainはこれを「prompted AI」から「ambient

皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋（@__timakin__）です。 2025年12月18日、AnthropicがAgent Skillsをオープンスタンダードとして発表しました。MCPに続く標準化の動きとして注目を集めています。 面白いのは、発表からわずか数日でOpenAIがCodex CLIとChatGPTに同規格を採用し、GitHub Copilotも対応を発表したこと。Anthropicが仕様を公開し、競合が追従する——MCPで見た流れが再び起きています。さすがAnthropicという感じで、一気に業界標準となりつつありますね。 この記事では、発表から約2週間で話題になっているスキルを厳選して紹介します。 この記事でわかることAgent Skillsの概要 カテゴリ別おすすめスキル10選 インストール方法と注意点 Agent Skillsとは

機能リリースと提供価値の変化細かい改善は頻繁に行っていますが、大きな機能リリースも多々ございました。 開発体験の観点は特に大きく、設定のバージョン管理により普通のソフトウェア開発と同様に安心してデリバリーできるように。 また、「ビジュアルエディター」というノーコード機能により、ソフトウェアエンジニアの方々でも画面を編集できるようになりました。 アクション（SQL実行やAPI呼び出し）を環境ごとにバージョン管理・有効化できる機能 ノーコードの画面作成機能、ビジュアルエディター ベースマキナは汎用基盤なので、AIプラットフォームのAPIとつなぎこんで知的作業を自動化できます。 また、ドキュメントのllms-full.txtを公開しているので、コーディングエージェントやNotebookLMでドキュメントを参照して頂き、よりロータッチ化が進みました。 「AI活用ユースケース」の公開 Noteboo

ただの殴り書き。 ChatGPT o1 Pro mode、契約して使っている。用途はふとした時の壁打ちなどもあるが、それはもともと精度高いのがわかっていたから特別今更試すことでもない。 2024年12月中旬時点でソフトウェアサービスの開発をどこまでこれに依存できるのか、限界を知っておきたいから試している。 多くの人に見られることを想定していないし、作っているものがこれだよというのを紹介する気持ちもないのでめっちゃ雑にかく。 動機 生成AIでの開発はよく「プロトタイピングに向いてる」「関数単位での生成やテストには向いてる」と言われる。 でもプロトタイピングなんて人それぞれ作るものの品質がまちまちで何を指しているのかわからない。 評価の仕方として上記の表現が曖昧に感じていたので、厳密な限界を体感したかった。 加えて、PdM系の人とエンジニアで何やら生成AIへの熱量の差があるのも気になっていた。

ありがたいことに継続的にご利用者様の数・ご活用頂く業務の幅が増え、積み上がるご要望に日々追いつくべく開発に邁進しております。 今回は先日ベースマキナがリリースした「ロール機能」に付随するお話です。 ベースマキナでは、以前から管理画面上で呼び出す処理ごとに、ユーザーやユーザーのグループ単位で実行を許可する機能があるなど、ガバナンス要求に答える機能を揃えてきました。 今回修正が行われたのはそれとは別のレイヤーで、ベースマキナ上の管理者向けの設定（接続先のデータベースやAPIの情報や、処理の登録、ユーザー追加など）を行う権限を細分化 & グルーピング設定を紐づけられるようにした、というものです。 この機能は成果物で見るとシンプルなのですが、権限管理にまつわる設計・開発はいつも魔物に立ち向かうようなもので、混迷を極めます。 そして、こと管理画面開発となるとその難易度は他の開発よりも高い、というのが

ポエムです！ 長いのでまとめローコード・ノーコードという言葉の括りは大きな意味をもたず、「プログラマブル」という表現が妥当 プログラマブルな基盤を作って売ることは、課題解決の幅を最大化する。複利でのアセット積み上げが可能で、ひいてはコンパウンド・スタートアップの地盤を作りやすい利点がある この基盤は最初から覚悟を決めて作らないと、後追いで構築するのが難しいため商材としての希少性が高い プログラマブルな基盤は、売り手に高い課題探索・抽象化能力と海外サービスへの強い関心が求められる こうした基盤を事業として成長させることは、将来「Sell work, not software」の時代が来たとしても生き残る手立てを作る最良の手段になりうる まとめても長いですね… はじめに皆さまこんにちは、株式会社ベースマキナの代表取締役社長を務めております高橋と申します。 現在弊社では、ソフトウェアエンジニアの

皆様、ChatGPTでCode Interpreterの機能がリリースされましたがお使いになりましたか？ 僕は大変有りがたーく日常使いさせて頂いており、活用方法について各方面のご意見を伺いたいですが、その話はさておき… こうした劇的な開発体験の変化が予感されると、度々繰り返される議題の１つが「エンジニアやコードの不要論」かと思います。 私自身がローコードツールを提供している会社の経営者なのですが（ヒューマンエラーを減らせる管理画面構築SaaS「ベースマキナ」をよろしくお願いします！）、この類の議論の盛り上がりと日頃情報を追っている最新のツール群との間を照らすと、ギャップを感じます。 端的に言うと、少なくともここ１年くらいで新しく登場するデベロッパー向けのツールを見ていると、コードが不要になる場面が増えると思いきや、逆にコードをしっかり書くツールが増えてきたな、という印象を持っています。 D

まとめプログラミングの未来では、最適化と自己修復がキーワードとなり、エンジニアは検品作業が主な役割になると考えられます。 ローコードツールは、否応なしにLLMとの共存を求められ、対応できなければかえって足かせとなってしまい淘汰されるでしょう。 そして、ローコードやノーコードの概念が意味を持たなくなるでしょう。 しかし、未来はシステムのチューニングに焦点を当てた業務になり、チューニングのための学習データを幅広に獲得できる現在のローコードプラットフォーマーは、きたる未来に備えて強力な武器を持てると考えられます。 ごあいさつこんにちは！ ローコードでかんたんに管理画面が立ち上げられるSaaS「ベースマキナ」を運営している、 株式会社ベースマキナの代表取締役社長の髙橋と申します。 サービスページはこちらです。管理画面の開発工数でお困りの方、手前味噌ながら大変便利なサービスに進化してきているので是非

要するに起業して、サービスを作りました。同志を募集しています。 長い自分語りなのですが、サービスを公開した直後の人間の所信表明として生暖かく読んでもらえればと思います。 サービスを公開しました先日、これまでステルスで開発・営業活動等をしていた社内管理画面作成サービス「ベースマキナ」を一般公開いたしました。 思った以上にお問い合わせであったり新規のご登録を頂き、感謝の想いに尽きません。 開発者一同が「きっとこの基盤なら自分達を含めWeb企業でサービス開発をしてきた方が何度も車輪の再発明をしてきた管理画面を作らなくて済むようになる」と信じて、持てる限りの技術でプロダクトを作っています。 公開時にも以前から相談させて頂いたエンジニアや事業者の方々にシェアいただき、一定話題に挙げていただきました。 ただ、自分としてはSaaSというサービスの提供方式やエンジニア文化を大事にするというのは手段で、本当

ポエム。 つまり？予算やチームのリテラシーに合わせて最速で作れて、チーム内で「俺ら高凝集低結合だなー」と思えるなら、アーキテクチャはなんでもいいと思えてきました。 前提・まだ割と収益が安定してないプロジェクトでの話です。お金があるなら好きにやりましょう。Go Bold。 ・DDDやクリーンアーキテクチャがダメとは言ってないです。むしろ自分は直近そこまで厳格ではないクリーンアーキテクチャでAPI書いてます。 ・以前こういうポスト書くくらいにはアーキテクチャのこと試行錯誤してました。 アーキテクチャ導入議論への疲労以前僕は、DDDやクリーンアーキテクチャを導入するという話が出ると積極的に顔を出すようにしていました。でも、最近は「導入しましょう」「既に適用してあるのでキャッチアップしてください」などの議論をするのに少し疲れてしまい、足が重くなったように感じます。もうおじいちゃんなので体力がないん

つまり・組織で情報の不透明性が問題になる時、必ずしもその不透明性は悪意や信頼性の無さから生まれるわけじゃなく、よかれと思ってやった結果生まれるかも知れない ・フルオープンにできなくても、情報の確定度合は可能な限りオープンにすべき 1on1で明らかになった不透明性この間1on1をチームメンバーとやっている時、情報の不透明性が問題になった。具体的にいうと、仕様議論が途中の機能について、「あの機能はいつから開発開始なんだろう」「開発スコープは？」という、疑問の声が上がっていた。 この不透明性が生まれたのは、例えば「外部企業と内密なやり取りがあって、隠しておきたい深刻な事情があった」とか、そういう背景からではない。 むしろ逆に、情報の不透明性の話になるたびに比較的僕の所属するチームは性善説で「できる限り共有しましょう」という議論が起こるので、上下の人間関係が悪いとかではない。教えてと言えばだいたい

この流れです。 前提基本的に自分はGoのサーバーサイドが主戦場で、カンファレンスにはよく顔を出します。最近はOSSを公開すればいい感じにGithub Trendsの上の方にきて目立つような、芸人っぽいムーブができるようになりました。 ですが、直近プライベートではGo以外にTypeScript(Next.js) でGraphQLのクライアント書いたり、仕事だと前はSwiftやらC++やらPerlやら色々使っていたので、他の方と比べると広く浅い経歴です。 また、大学に入ってから学習を始めましたし、当時はドットインストールが出始めたくらいで、基本的には書籍で勉強していました。大学では授業でFORTRANの授業を取りました。内容は意味わからなかったので同級生に寄生してました。 Progateとかプログラミングスクールとかには頼ってませんでした。無かったので...。なので、「幼少期からBASICを触

別に大した話ではないけど、職位が変わって肩書きに仮にもマネージャーと付き、人との対話に時間を割いていかねばという状況になったため、人やら組織やらアジャイルやらなんやらについて考える時間を意図的に増やそうとしている。 1on1とかで、「最近何か課題に思ってることかありますか？手助けできますか？」みたいなことを話さなきゃいけないのだろうが、人はそんな簡単に所属する組織や個人に対するフィードバックを本音でしてくれるものだろうか？と考えたりする。ましてや肩書き変わったからって別に中身が突如変化したわけじゃないやつに「最近調子どう？」みたいなことをいきなり言われても、うるせえよとしか思わないのではないか。 仕事上の横のつながり、人と人とのやり取りの中では「信頼残高」という言葉でもって、その人がそれまで積み上げた実績に応じて信頼度が上がり、より重要な仕事や報酬を与えようとする現象を説明する。だけどこの

当ポストはGo Advent Calendar 2019の5日目の記事です。基本ポエムを書いていて技術記事を書く感覚が鈍っていますが頑張ります。 今回はGoでheadless browser（Chrome）を用いた、動的な画像生成を行うというテーマで書きたいと思います。 なぜ画像生成したいのか？人はなぜ画像を生成したくなるのでしょうか？僕は漫然と画像を生成するのは、時間に限りがある身としてはよくないな、と思います。ということで理由が必要なのですが、最たる例はOGP画像の生成とかじゃないでしょうか？ あるいは任意のLGTM画像を生成したくて、文字を画像にかぶせたり、インスタグラムVer1.1みたいなサービスをローンチしたい時に、フィルター加工を実装したかったりするかもしれません。 Goで画像生成するには？Goで画像生成する方法に関してはこの１、２年でpo3rinさんや僕がしばしば登壇して解説

基本忙しいな〜と思いつつ、幸いにも仲良く仕事ができてることが多い。その理由を考えてた時に気づいたことをまとめたのがこの文章になる。ここで言いたいことはつまり、「機能を削ることはユーザーと開発チーム双方にとって、恐らく各位が考えている以上に良いことだ」ということだ。 なお、サムネは「機能を削ぎ落としていく過程はまるで彫刻製作のようだ...」と一瞬考えた時に程よい画像をとってきたのだけれど、単純にキモいなと思ったのと、的を射ているようで射てない気がしたし、プロダクト開発も彫刻もそんな知らないので、可及的速やかに忘れることにした。 いかにしてチームは殺伐となるかリリース間際やプロダクト開発が長期化すると、えてしてチームは殺伐としがち。自分が関わったチームでのプロダクト開発では、半々で殺伐なシーンと平和なシーンだった。 殺伐な開発は、その後チームの人間関係に消しがたい遺恨を残し、結果退職や倒産とい

「誰かエンジニアで暇な人いませんか？」個人的にカンファレンスとかでエンジニアの知り合いの数が多くなったせいか、優秀なエンジニアの知り合いを紹介して欲しいと相談されることが非常に多いです。 「本当に優秀な人」以外を繋ぐならすぐ紹介できます。しかし、本気で生産性が高い人に声をかける場合、他のリファラル案件にも負けない条件を提示しないと絶対に来てくれないし、下手な紹介なんかしたら「僕と対象者の関係」「対象者の人生」「会社のプロダクトの成功」の全ての面で不幸が生じます。誰でもわかることだと思いますが、その割に結構雑に依頼を投げる人が多いな、という印象があります。優秀なエンジニアで仲良くしてもらってる人は、雑に紹介できるほど半端な友好関係ではないので、適当に繋いだりはしないです。 紹介可否の格差ある一定の基準をクリアしていると、すぐに紹介できます。紹介できない場合はよほど事情が変わらない限り良い報告

前置きCircleCI Orbsというのは、CircleCIのバージョン2.1以降で有効になった、CI/CDワークフローの一部を共通パッケージとして切り出す仕組みです。 CircleCIはバージョン2.0のメジャーアップデートを経て、一気に実行速度が上がりました。しかし、プロセスの共通化をするにはyamlの記述方法を工夫する以外は特に打ち手がありませんでした。 Orbはまさにその解決策として提示された、CIプロセスのパッケージ化です。 なお、バージョン2.1になったことで、いくつか追加の概念が登場しました。 executors, commands, jobsです。この辺は公式ドキュメントを見ていただくとして、ざっくり言うとexecutorsが実行環境、commands, jobsが実行プロセスの共通化です。 OrbはDockerのイメージと同じく、作ったものをインターネット上で公開するレジ

開発者向けのドメイン、「.dev」の登録受付が開始された。timakin.devはちゃんと俺が取った。みなさんも取りましょう。 で、昨日vim.devのドメインが個人によって取得され、そのリダイレクト先がEmacsのサイトになっていたことで、物議を醸した。HackerNewsにも載ってた。 この行為に対し、観測範囲では ・「やりすぎだ、同じデベロッパーとして辟易する」という人 ・単に"エディター間の宗教戦争"に関するユーモアあるネタだと受け取る人 の二極化が見られた。ちなみに僕はそこまでエディタ戦争に関心はないし、結構あとあと迷惑になる行為かなーと思うので、どちらかといえば前者寄り。 僕の話は置いておいて、前者はOSS開発者やカンファレンス主催者などが多い印象を持った。だから前者の意見が偉いとかそういうわけではないのだけれど、おそらく以下の２つのポイントで認識が大きくズレているから、二極化

tl;dr勉強会で寿司とピザ出すの極力やめませんか 餌としての寿司とピザ先日雑にこのようなことを呟いた。 これは、某社のエンジニア求人イベントの広告だったのだけれど、見た瞬間は餌で釣ろうとしてるような魂胆が透けて見え、それに対する嫌悪感を抱いた。 だけどその直後、「まあそうはいってもエンジニアの勉強会って寿司かピザしか頼まないし、それさえあれば人が集まると思われてもしょうがないくらいにワンパターン化してる主催側も悪いよな」と思ったりした。 念の為書いておくけど、自分が勉強会の担当になった時、ピザはサルバトーレクオモのうまいやつを少なめで注文したりして、結局ピザを注文してて、完全にブーメランである。とにかくピザに罪はない。 勉強会テロリスト寿司とピザが毎回出るとわかってると、テロリストみたいなやつがくる。 ・懇親会の直前だけきて台風みたいに寿司をかっさらって行くやつ ・寿司のネタだけ食ってシ