Mirror

最近の活動履歴を横断すると、関心は「AIプロダクトをどう作るか」から、AIが入り込んだ開発プロセスをどう設計するかへ広がっているように見える。

以前からの軸は、AIが次の一手を選び続ける判断ループだった。目的、制約、予算、停止条件を人間が決め、個別の実行や比較はAI側に持たせる。その読みはまだ残っている。ただし新しい重心は、AIシステムが存在する場所を、プロダクトの中だけでなく、タスクの受け渡し、実装、検証、改善を含む開発プロセス全体へ広げている点にある。

AIで実装が速くなるほど、詰まる場所は実装そのものではなく、動くか、使いやすいか、壊れていないか、顧客に届けてよいかを確かめる部分になる。ここでのShift Downは、検証を早めるだけではなく、開発者とAIの両方が使える確認の足場を下に置く考え方として読める。

Browser QA、デザインハーネス、Software Factoryへの関心は、この流れの中でつながっている。AIを速い作業者として既存工程に置くだけでは、ターミナル、Git、PR、レビューといった人間向けの形が、AIの能力の使い方まで決めてしまう。いま問われているのは、どの工程を残すかではなく、何を必要だから残し、何を慣れているだけで残しているのかである。

重要なのは、ハーネスを単なる作業環境としてではなく、証拠を残し、判定基準を改善し、修正と再検証へ返す仕組みとして見ている点である。AIを走らせる足場は、プロンプトやルールファイルだけではなく、失敗を次の検証条件へ戻す運営基盤になっている。

新しく前に出ているのは、この運営基盤の中に、意味を読む小さなセンサーをこまめに差し込む発想である。規約を守ったか、今回の作業にどの知識が効くか、PRを止めるべきかといった判断を、人間の注意や大きなレビューだけに寄せず、速く安く呼べる分類問題としてラインの途中へ置く。ハーネスは、AIに作業させる面であると同時に、作業の各段階で小さな判定を積む面にもなっている。

この文脈では、エージェントが自動でコードを書き直すまでの時間も、単なる速さの指標ではなくなる。書き直しを任せきれない理由は、エージェントが正しさを自分で確かめられないことにある。実データの入出力、触ってよい範囲、実行したことの記録、触れてはいけないものの線引きが揃って初めて、速く直すことを信用できる。TTRは、速度ではなく、検証とガバナンスの成熟度を映す指標として読める。

この足場は、汎用ツールをAIに触らせるだけでなく、特定の仕事に合わせて狭く作ったコード、DLS、テンプレートにも伸びている。独自のスライド記法や業務用の小さな操作面を考える流れは、AIが扱いやすい形へ作業そのものを作り替える、Code as Harnessの方向として読める。

同時に、そのハーネスは個人の作業台だけに閉じていない。AI活用が個人の生産性から組織のプロセスへ移るほど、複数人が同じAIの作業面、証跡、判断基準を共有できるかが前に出る。マルチプレイヤーなエージェントハーネスへの関心は、AIを自分専用の補助輪ではなく、チームで運用する開発基盤として見始めている兆しに見える。

ここ数日の記事化では、その共有ハーネスにもう一つの条件が足された。SlackにAI botが並んでも、見えているのが依頼と返事だけなら、作業している場所はまだ一人用である。複数人が同じセッション、コンテキスト、成果物へ入り、レビューする人が直接AIに直させられるようになって初めて、AIはチームの作業面になる。

そのとき、人間の役割は単なる中継から外れる。AIが書いた返事や修正をそのまま自分の名前で返すなら、そこには読んだこと、確かめたこと、理由を説明できることへの責任が残る。AIの内側ループを速くするほど、人間が外側で持つべきものは、方向や評価基準だけでなく、発話と決定を引き受ける作法にも広がっている。

ソフトウェアファクトリーの読みも、同じ方向へ更新されている。エージェントが仕事の流れを押さえると乗り換えにくさが生まれるが、工場のライン側が振り分け、履歴、評価を持てば、エージェントは差し替え可能な一工程になる。ロックインは消えるのではなく、エージェントからラインへ移る。だから「開発」を誰が再定義するのかという問いは、どのモデルを使うかではなく、仕事の流れと評価の置き場所を誰が設計するかの問いになっている。

この読みでは、AIネイティブな開発の中心問題は、どれだけ速く作れるかだけではない。内側のループはAIが回し、人間は外側で方向、制約、評価基準を持つ。その分担を、顧客へ届ける速さ、仮説を更新する速さ、開発プロセス自体の進化へどう接続するかが、次の問いとして前に出ている。

もう一つの新しい輪郭は、AIネイティブなプロダクトを、抽象的な業務効率化ではなく、人間が文脈を読みながら繰り返している知的単純作業の発見と、その仕事が人の不在時にも回る仕組みの設計として見ていることだ。

業務ヒアリング、顧客インタビュー、CRM、議事録、音声入力への関心は、同じ方向を向いている。人間の頭の中や会話、メール、会議メモに残ったままの文脈を、AIが扱える材料へ変えたいという関心である。

ここでのAIは、単にフォーム入力を肩代わりするものではない。相手の課題を聞き、散らばった情報をつなぎ、次に確認すべき問いを出し、プロダクトや営業の判断へ戻す役割を持つ。

この関心は、現場の一次情報を人とAIの判断や実行を支えるコンテキストへ変える、という言い方にも近づいている。AIが自律的に動くほど、入力される文脈の質と、後から確認できる証跡の設計がプロダクトの中核になる。

Qual at Scaleの記事では、この線がかなりはっきりした。AIインタビューは、顧客の声を人間が読むための調査だけではなく、社員や業務の知識を聞き出し、地図、手順書、判断記録、エージェントが読むコンテキストへ変える方向へ広がっている。聞いた内容の読み手が人間だけではなくなったとき、インタビューはレポート作成ではなく、AIが動くための業務定義を更新する仕組みになる。

その場合に大事なのは、話を聞くことだけではない。資料、画面録画、操作ログ、Slackやメールの履歴を読み、分からないところだけを人に聞く。人が語る仕事と、実際に行われている仕事のずれを埋めることが、AIプロダクトの価値になっていく。ここでは、Context MiningやProcess Intelligenceが、単なる可視化ではなく、エージェントが実行できる会社の地図づくりとして読まれている。

最近の違和感は、AIを使える場所だけでなく、AIで操作できない場所にも向いている。自然言語で状態を変えられる体験に慣れるほど、既存ツールを手でなぞる操作は、ただのUIではなく、まだAI化されていない摩擦として見えてくる。画面録画、DOM、ARIA tree、操作ログを、業務理解やタスクマイニングへ戻せないかという関心も同じ線上にある。

だから、AIプロダクトの探索は「どの業務を自動化できるか」だけではなく、「どの知的単純作業なら、AIが先に動き、人間が必要なところだけ戻れるか」「どの操作は、もう言葉で済むはずなのか」「業務のas-is/to-beを描ける人と、AI化を実装できる人をどう組ませるか」を探す作業になっている。

創作やデザイン側の流れでは、AIを使った制作を、勢いで公開する量産ではなく、品質ゲートを通す運営として扱っていることが続いている。

制作ログでは、アイデアや初期案を増やすよりも、静止画で伝わるか、スマホ幅で読めるか、人間の感情が画面説明に負けていないか、という確認が繰り返されている。公開データがない段階では、反応分析よりも作品として成立する入口を先に見る。

デザインにおけるハーネスという言い方は、この流れを別の領域へ移している。AIに何を見せ、どの制約を渡し、どの基準で検証するかを決める仕事は、エンジニアリングだけでなく、画面、資料、体験設計にも広がる。

外部事例への反応でも、ゼロから生成することより、実物に忠実に補正し、通過したものだけを公開する設計に目が向いている。ここでも焦点は、生成の派手さではなく、何を実物として尊重し、どの条件を満たしたら外へ出してよいかである。

ショートドラマの運営メモでは、AIが脚本を出すだけでなく、シリーズ継続、打ち切り、次回変数、投稿権限、分析待ちの扱いまで持つ前提になっている。これは制作というより、小さなIPをAIが運営する実験に近い。

ここでのAIは、脚本や素材を出すだけの道具ではない。候補を比較し、捨てた理由を残し、通過条件を明文化し、外部公開の権限だけは人間側に残す運営者として扱われている。

この考察は、AIエージェントの開発運用ともつながる。自律性を上げるほど、公開、投稿、課金、外部送信の前に、何をゲートにするかが重要になる。

rkagaya.post、外部発信、docs、Weekly Briefingの設計をつなげて見ると、サイトを単なる完成記事の置き場ではなく、集めた素材を人に説明できる判断文へ編み直す場所にしようとしている。

特にWeekly Briefingでは、リンク集や箇条書きの要約ではなく、何が起きたか、何が示されたか、実装者とCTO/CPOが何を確認すべきかまで段落で書く方向に寄っている。採用しなかった候補も残し、選定の境界を後から読めるようにする。

Mirrorでも同じ構えが見える。記事、登壇資料、短い投稿、制作ログを媒体別に並べるのではなく、同じ問いがどの形で繰り返し現れているかを読み、R.kagayaの最近の考えを複数のノートとして育てる。

今回のサイト更新では、記事の中身だけでなく、見せ方もこの方向へ寄っている。動く表紙、強い記事シェル、図解つきの長いレポート記事は、考えたことをただ保存するのではなく、読み返せる形の公開物にするための編集面として機能している。

今回の読みでは、AIエンジニアリング、メディア運営、短い創作実験は別々の関心ではなく、AIが動く条件と、人間が引き受ける判断をどう編集するかという一つの問いに集まっている。