港町大原を背景に、猫のキャラクターがノートパソコンで生成AIと仕事をしているイメージ
mori.chiba.jp — 港町・いすみ市大原から、AIと一緒に未来をつくる。生成AI活用・システム開発・クラウド/DX支援。CEO くろたぐ。

REMOTE WORK × GENERATIVE AI × OHARA

港町で、
AIと仕事をする。

千葉県いすみ市大原。
海のそばから、世界につながるソフトウェアをつくっています。

SCROLL ↓
GENERATIVE AI·RUST·TAURI·REMOTE WORK·OHARA PORT· GENERATIVE AI·RUST·TAURI·REMOTE WORK·OHARA PORT·
ABOUT THIS SITE

東京から離れても、
仕事の中心からは離れない。

mori.chiba.jp は、港町・大原で暮らしながら、生成AIとソフトウェアをつくる日々を紹介する個人サイトです。

窓の外には太平洋。画面の中には世界最先端のAI。静かな土地で、にぎやかな技術の未来を追いかけています。

いすみ市大原の海辺。芝生の広場の先に太平洋の水平線が広がる
窓の外は、この景色。— 大原の海辺
PROFILE

中の人。

ミニコン、メインフレーム、LISP、国産LISPマシン、そして生成AIへ。時代ごとの計算機と向き合いながら、ソフトウェア開発の可能性を追い続けています。

SOFTWARE DEVELOPER / AI COLLABORATOR

海辺でコードを書き、
AIには細かく注文をつける人。

千葉県いすみ市大原の港町を拠点に、生成AIと対話しながらソフトウェアを開発しています。設計から実装まで、AIを相棒に細かく注文をつけながら形にしていくのが日々のスタイルです。

コンピューターの低レイヤーと長く向き合ってきた経験を土台に、いまはこれからのソフトウェアの「つくり方」そのものを探っています。歩んできた道のりは、下の COMPUTING JOURNEY をご覧ください。

朝は海、昼はコード

早朝の港を走り、海や空を眺めてから仕事を始めます。場所の静けさが、考えるための余白になっています。

技術は暮らしの道具

「作れるか」だけでなく、「毎日使いたくなるか」を重視。自分や身近な人が実際に使える形まで仕上げます。

COMPUTING JOURNEY

計算機と歩んだ道。

装置が大きく、記憶容量が小さかった時代から、自然言語でAIと設計を語り合える時代まで。

( START )

NEAC-3200 / IBM System/370

ミニコンピューターとメインフレームで、コンピューターとの本格的な関わりが始まりました。

( LISP )

アセンブリ言語でLISPを実装

アセンブリ言語でLISPインタープリターを開発。学生の言語学習などに活用されました。

( AI MACHINE )

ELIS / TAO プロジェクト

日本で開発されたLISPマシンELISと、言語・開発環境TAOのプロジェクトに参加しました。

( MS-DOS / DTM )

ウインドウシステムから音楽ソフトへ

独自のオブジェクト指向GUIを開発し、その上にmusiComposerを構築しました。

( NOW )

生成AIと開発の未来を研究

生成AIを開発の全工程で活用し、人とAIが協働する次世代のソフトウェア開発を調査・研究しています。

MS-DOS & DTM

Windowsが普及する前に、
ウインドウをつくる。

MS-DOSが主流だった時代、メニュー、ボタン、スクロールバー、ダイアログなどを部品として扱える、独自のオブジェクト指向ウインドウシステムを開発しました。

そのシステムの上で開発したのが、ヤマハ株式会社の委託によるDTMソフトウェア 「musiComposer」 です。

DTMとは

Desktop Musicの略。パソコンを使って作曲、編曲、演奏、音色編集などを行う音楽制作のことです。

ヤマハ株式会社の委託により開発した「musiComposer」は、DTMがまだ新しい分野だった時代に、先進的なソフトウェアとして評価されました。その内容を解説した『musiComposer 徹底解剖書』も出版されています。

ヤマハ musiComposer 徹底解剖書の表紙
musiComposerの五線譜入力画面
musiComposerのミキサー画面

『musiComposer 徹底解剖書』と、当時の操作画面

“
いいコードは、
いい景色から。

都会の速度と、海辺の余白。どちらかを選ぶのではなく、両方を仕事に持ち込みます。

壱

AIを「道具」で終わらせない

答えを受け取るだけでなく、考え方を伝え、反論し、検証しながら共同作業を進めます。

弐

開発の全工程を会話にする

コーディングだけを切り出さず、問題の発見から完成後の改善までを一つの対話として扱います。

参

難しい技術を、自然な道具へ

Rust、Tauri、クラウド、認証技術などを、専門知識を意識せず使えるソフトウェアへ仕立てます。

WORKS

海辺で、こんなものも
つくっています。

市販の道具に自分を合わせるより、自分の使い方に合う道具をつくる。その過程も生成AIと楽しんでいます。

⌘

AI Native Development

要件整理から実装、デバッグ、改善まで。対話型AIを開発チームの一員として扱う、新しいものづくり。

GENERATIVE AI
↔

Cloud File Tools

Google Drive や Linux のファイルを、Windowsのエクスプローラーに近い感覚で扱うツール。

RUST / TAURI
◉

Private Browser

広告やトラッカーを抑え、自分の使い方に合わせて育てる、軽快なプライベートブラウザ。

WEB TECHNOLOGY

PLAN

→

DIALOGUE

→

BUILD

→

VERIFY

→

PLAN B

PHOTOS

ミラたぐ君たち。

大原で暮らす、看板猫たちのアルバム。

DIARY

日記。

海辺の日々と、開発の記録。気が向いたときに、気ままに更新します。

いすみ市議会議員一般選挙 <><><> 新たに挑戦する若い候補者の皆さん。当選した暁には、何があっても「現状維持」に固執する議員たちに取り込まれることなく、初心を貫いてください。 これまでの慣習にとらわれず、市民の目線に立って、より良い議会へと変えていく。その若い力と行動力に期待しています。

この日の記事へ →

Androidアプリの解析からAPIへの侵入――本当に問題だったのは何か <><><> Webサービスへの不正アクセスを調査したJPCERT/CCは、攻撃者がAndroidアプリの配布ファイルや解析ツール、スクリプトなどを用いて標的を調べていたとみられる痕跡を発見しました。AIも利用されていたようです。 ここからは推測ですが、攻撃者はアプリを解析し、サーバーとの通信に使われるAPIの仕様を調べたのではないでしょうか。通信先のURLやパラメータ、認証方法などを把握し、アプリを介さずAPIを直接呼び出して、弱点を探った可能性があります。 そのAPIは、REST APIだったかもしれません。REST APIとは、アプリがHTTP通信を通じてサーバーのデータを取得・更新するための、広く使われる仕組みです。例えば、画面に利用者情報を表示する際にも使われます。呼び出し方が分かれば、正規のアプリを使わずに要求を送ることもできます。 しかし、APIの存在や仕様を調べられること自体は、脆弱性ではありません。アプリは利用者の端末で動く以上、解析されることを前提に設計すべきです。重要なのは、APIを直接呼ばれても、サーバー側の認証・認可や入力検証によって不正操作を防げるかどうかです。 生成AIの進歩は、こうした調査の効率も高めています。守る側も、AIを活用して想定外の呼び出しや権限の逸脱を繰り返し検証する必要があります。 問われているのは、アプリの中身を知られたことではありません。中身を知られても安全なシステムになっているか、という設計と検証の質なのです。

この日の記事へ →

生成AIを、過去の常識で理解していませんか? <><><> 生成AIをめぐる議論には、数年前の技術水準を前提にしたものが少なくありません。しかし、その進歩は驚くほど速く、半年前の知識さえ古くなることがあります。 2020〜2022年は、文章や画像、プログラムを「生成するAI」の時代でした。2023年には検索や外部ツールを使うようになり、2024年には高度な推論やコンピューター操作へと進化しました。 大きな転換点は2025年です。開発環境の構築からビルド、テスト、エラー解析、修正まで実行する「仕事を遂行するAI」が登場しました。さらに2026年には、複数のAIエージェントが設計、実装、検証などを分担し、協調して働く仕組みも実用化が進んでいます。 これは単なる性能向上ではなく、AIの役割そのものの変化です。人間の役割も、作業を細かく指示することから、目標や制約条件を定め、成果を検証することへと変わりつつあります。ただし、AIがテストを実行しても、成果の正しさが保証されるわけではありません。 こうした変化は、生成AIに質問して回答を読むだけでは理解できません。実際に仕事を任せ、条件を変え、結果を検証し、修正を繰り返す。その実践を通して初めて、現在の能力と限界が見えてきます。 問題なのは、生成AIの利用経験が少ないことではありません。古い知識を更新しないまま、現在の技術を評価してしまうことです。 それでは新たな可能性を見逃すばかりか、周囲にも誤った認識を広めかねません。 大切なのは、過去に何ができたかではなく、今、何ができるようになったのかを理解することです。 技術が日々進化している以上、私たち自身の理解もまた、進化し続けなければならないのではないでしょうか。

この日の記事へ →

先日、「いすみ議会だより」を「広報いすみ」から独立させ、内容もさらに充実させてはどうかと、いすみ市議会へ提言しました。 議会事務局から丁寧な回答をいただき、「議会だより」は以前は独立した冊子として発行されていたものの、より多くの市民に読んでもらうことを目的に、平成22年から「広報いすみ」に組み込まれたとのことでした。 それから約16年。現在の議会だより編集委員会でも、独立した冊子のあり方を含め、さまざまな意見が出ており、今後検討していくとのことです。 今回提案した、賛否が分かれた議案の論点を分かりやすく伝えること、市民の声や厳しい意見も取り上げる双方向の紙面づくりについても、議長や編集委員へ伝えていただけることになりました。 議会中継が実現した今、その次の一歩として、「議会だより」も市民にとって、より身近で分かりやすいものへ変わっていくことを期待しています。

この日の記事へ →

大原はだか祭り <><><> 小浜八幡神社の神輿は、寄せては返す波に揉まれながら、20分以上も海の中にありました。 神輿を守り、支え、声を掛け合う氏子たち。海と人と神輿がひとつになるような、力強い「汐ふみ」の光景です。 そして海から上がっても、祭りの勢いは止まりません。神輿を担いだまま浜辺を何度も駆け回り、砂浜には掛け声と足音が響き渡ります。荒い波にも負けない熱気――小浜八幡らしい、勇壮なひと幕でした。

この日の記事へ →

ミラドールの注文管理システムを、アクティブ・スタンバイの冗長構成にしました。 通常は現用系で処理し、障害が発生すると待機系へ切り替えて運用を継続します。そして今回こだわったのは、切り替わるところまでで終わらせなかったこと。障害を起こした現用系が復旧したことを確認すると、システム全体の状態を整えたうえで、正しく現用系へ戻るところまで考慮しています。 冗長化は「障害時に切り替われば完成」ではありません。障害の発生から切り替え、復旧、そして平常状態への復帰まで、一連の流れがきちんと閉じて初めて安心して使える仕組みになります。 小さな店の注文管理システムとしては、少々やり過ぎかもしれません。それでも「動く」だけでなく、「壊れたとき、そして直ったときにどう振る舞うか」まで考えてしまうのは、技術者の性分なのかもしれません。

この日の記事へ →

FROM OHARA, TO ANYWHERE.

港町からでも、
世界を少し便利にできる。

そして、ときどき猫の手も借ります。

Today 606 Total 76,829