業務部門向け
HOZEN保全記録をもとに、原因調査と再発防止を支援。提供中 · 実証相談Millwright業務の手順を定め、AIをその範囲で動かす。AI-RPAは設計・検証段階開発チーム向け
Hemkar人とAIの開発作業を、検証できる成果にまとめる。設計・開発段階FlashRouter複数のAIモデルの接続・版・利用量をまとめて管理。企業向けは個別相談IngaDB自社システムに組み込める因果分析データベース。v0.1.0 · セルフホスト · 提供中Hemkar人とAIの協働開発ワークスペース
人が目的を決め、AIと開発者が作り、人が証拠を確認する。Hemkarは、その計画・担当・報告・判断を共有し、別々の仕事を確認できる一つの成果につなぐ開発ワークスペースを目指しています。

それで十分なら、管理ツールを増やす必要はありません。GitHubで課題・コード・履歴を管理し、Claude Codeに実装やテストを支援してもらう進め方でも、必要な情報と判断を共有できます。
ただ、複数の人やAIが参加すると、「誰に何を任せたか」「どの問いの回答を待っているか」「何を根拠に受け入れたか」を追う負担が増えます。Hemkarは、これらを一つの流れとして共有しやすくすることを目指します。
大切なのはツールを増やすことではなく、必要な人とAIが、同じ目的と根拠で次に進めることです。
誰のために、何を作り、何ができれば完成か。
誰が何を進め、どこまで変更してよいか。
何が進み、何が不明で、誰の回答が必要か。
どの条件を確認できたか。何が未確認か。
なぜその判断をしたか。次の担当が何を引き継ぐか。
AIの実作業は手元のコンピューターで行い、CLIで共有側とやり取りします。Hemkarはコードを実行する場所ではなく、合否は人が決めます。接続、計画の公開、作業開始の許可は、それぞれ別の段階です。
ここでいうレビュアーは、ソースコードを読む人ではありません。開発者やAIだけでは決められない問いに、業務の立場から答える人です。たとえば売上CSVの開発なら、問われるのは次のようなことです。
「営業がこのCSVで確認したいことは何ですか?」
「売上日は、受注日と計上日のどちらを基準にしますか?」
「取消済みの売上は含めますか?」
「必要な列が一つ欠けています。この状態で受け入れますか?」
開発者とAIは、背景・選択肢・影響・推奨案・証拠を添えて、答えられる形に問いを整えます。ソースレビューや仕様との適合確認は、別の役割として扱います。
依頼は「売上をCSVで取り出したい」。最初に期間、必要な列、権限、合格条件を決めます。以下は架空の開発例です。
実装した。条件を満たしたとは限らない。
AIが報告した。まだ検証されていない。
個別のチェックに合格。ほかの条件は未確認。
人による成果の確認待ち。
ここから先は人が判断対象の条件を検証した状態。
ダウンロードとテストが成功しても、完成条件に定めた列が欠けていれば差し戻し。
AIの作業が止まったら、最後の報告と作業権の経緯を確認し、そのまま続けるか、担当を交代するかを人が決めます。
「Stale(停滞)」は古さを示す表示です。表示だけで担当が自動的に外れることはなく、手元の作業も消えません。

Hemkarは、V字モデルに代わる工程モデルではありません。V字モデルが「何を何で確かめるか」を整理し、Hemkarが「誰が実行し、何を根拠に誰が判断したか」を共有します。
対応は代表例で、名称や粒度は組織により異なります。

開発中の画面デザイン案です。表示している人名・プロジェクト・作業は設計用の例で、実際の稼働状況ではありません。
進捗を聞くだけでなく、仕事が止まる原因と、判断の分担を整える。
手で書く作業に加え、AIの案を比較・修正・検証し、保守できる成果にする。
技術判断、設計、コード理解、検証、説明の責任。自分が入力していないコードでも確認を省略しない。
| Microsoft Project/Planner | 工程、日程、依存関係、リソース。いつ終わり、誰をどこに配置するか。 |
|---|---|
| Backlog | 課題、担当、進捗、チームのやり取り。誰が何を担当し、どこまで進んだか。 |
| Jira | 課題とワークフロー。仕事をどの状態・手順で進めるか。 |
| Notion | 課題、文書、知識、AI支援。組織の仕事と知識をどうつなぐか。 |
| Hemkar | 人とAIの作業範囲、証拠、判断。何を任せ、何を根拠に受け入れるか。 |
併用する場合は、Projectで工程、Backlog/Jiraで課題、HemkarでAI協働の経緯を扱う分担が考えられます。外部サービスとの自動連携は今後の構想です。比較は重点の違いを示すもので、優劣の評価ではありません。各製品の名称は各社の商標です。